Re: [dev] [hack] Having dmenu provide hints about current selected entry

On 26 November 2010 16:33, Christophe-Marie Duquesne
<chm.duquesne_AT_gmail.com> wrote:
> On Fri, Nov 26, 2010 at 3:04 PM, Dieter Plaetinck <dieter_AT_plaetinck.be> wrote:
>> the delay caused by dmenu waiting for stdin input to be complete
>> is noticeable.
>
> Actually, while performance also matters, the thread thing is not
> primarily a matter of fast processing. It is just that if you wait for
> the input to finish before allowing the user to interact, you miss the
> point of allowing feeding additional entries to this input from the
> suggestions (since these suggestions can only happen once user can
> interact).

Ok that's a better reason for it.

> On Fri, Nov 26, 2010 at 3:43 PM, Connor Lane Smith <cls_AT_lubutu.com> wrote:
>> No, to do this would be trivial. It's just that certain suckless
>> people are rather aggressive to the idea of using pthreads for
>> anything.
>
> I was more or less aware of this but did not see any other options.
> @Troels: I did not know select(), but I am going to read about it.
>
>> The first aspect of your patch, the incremental output, already
>> exists.
>
> Thank you, I did not know about it.
>
>> The threaded input is neat, and I am perfectly willing to
>> add it into dmenu proper. Though I expect others will not share that
>> willingness.
>
> It isn't. I experimented a crash when messing with it, so expect to find bugs.

I guess those crashes are related to concurrent accesses to the same
data structure. In the end the thread would need to work on a copy and
the items propagation would need to be protected by a mutex. Hence
things will become a bit ugly.

I don't think the select() approach would increase the readability a
lot, but at least it would implicitly disallow concurrent accesses to
items.

I think overall the threaded version should be favored, for now as a
patch I would say.

Cheers,
Anselm
Received on Fri Nov 26 2010 - 16:43:39 CET