On 26 November 2010 16:33, Christophe-Marie Duquesne <chm.duque...@gmail.com> wrote: > On Fri, Nov 26, 2010 at 3:04 PM, Dieter Plaetinck <die...@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 <c...@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
