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

From: Anselm R Garbe <>
Date: Fri, 26 Nov 2010 16:43:39 +0100

On 26 November 2010 16:33, Christophe-Marie Duquesne
<> wrote:
> On Fri, Nov 26, 2010 at 3:04 PM, Dieter Plaetinck <> 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 <> 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

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

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

This archive was generated by hypermail 2.2.0 : Fri Nov 26 2010 - 16:48:05 CET