Thinking about kqueue's and pthread_cond_wait

[Alfred Perlstein]

Interesting, I had the same problem, specifically I wanted to
have a thread that both selected on fds, but also selected on
some queues.  Because I had no way to hook my queue's condvar
directly into select I had to implement the pipe technique you
describe.

I'd say go for it, sounds very useful.

-Alfred

* Randall Stewart <rrs at lakerest.net> [100210 07:39] wrote:
> Alfred:
> 
> Basically I would like to have a dispatch/reactor loop that can
> wait on multiple events. Including a condition variable that might
> be in shared memory or for that matter some other thread awakening
> it to do something without having to create a pipe and write/read
> a byte.
> 
> A peer process could also "wake" the condition variable and this
> would then show up as an event in my dispatch loop, assuming the 
> cond
> variable and mutex are in shared memory that is... For example a
> peer could plop some data in shared memory (via a shm queue or
> some such other construct) and then do a cond_wake() and ta-da
> coolness ;-)
> 
> It would let you have say a single pool of threads handling your
> reactor/dispatch loop..  Excessive threads are not a good thing so
> being able to have one pool.. and not fork off a bunch of extra
> threads is a "good" thing IMO..
> 
> 
> R
> On Feb 10, 2010, at 6:29 AM, Alfred Perlstein wrote:
> 
> >It sounds really interesting, do you have a particular use-case
> >you can share that would show how to use this at a macro-level?
> >
> >Why would someone kqueue on multiple (or single) condvars?
> >
> >There's probably some exciting reasons why.
> >
> >-Alfred
> >
> >* Randall Stewart <rrs at lakerest.net> [100210 06:09] wrote:
> >>All:
> >>
> >>I have once again come around to thinking about joining pthread 
> >>cond
> >>waits and
> >>kqueue's.
> >>
> >>After thinking about it, I think its doable.. with something 
> >>like a:
> >>
> >>pthread_cond_wait_kqueue_np(kev, cond, mtx, ucontext)
> >>
> >>Then you can use kev inside a kqueue i.e.
> >>ret =  kevent(kq, kev, 1, outkev, 1, NULL);
> >>
> >>Now when you saw the event:
> >>  if (kev.filter == EVFILT_UMTX){   /* not sure about the name 
> >>  here  */
> >>       pthread_kqueue_cond_wait_ret_np(kev, cond, mtx, ucontext)
> >>       do_user_action(cond,mtx, ucontext);
> >>   }
> >>
> >>Which would fill in the cond/mtx and ucontext for the user.
> >>
> >>Now does this sound useful to anyone.. i.e. should I spend the 
> >>time
> >>making it work?
> >>
> >>The only down side to this is that it would have to allocate 
> >>memory  so
> >>one would need to do a:
> >>
> >>   pthread_kqueue_cond_wait_free_np(kev)
> >>
> >>After you were done.. and I think it would be best for this to
> >>be a ONE_SHOT.. i.e. you have to re-arm it if the event 
> >>happens...
> >>Of course until you free it that can be as simple as passing the 
> >>kev
> >>back down again (i.e. no pthread_cond_wait_kqueue_np() needed).
> >>
> >>Comments? Thoughts?  i.e. especially is it worthwhile doing?
> >>
> >>
> >>Thanks
> >>
> >>
> >>R
> >>------------------------------
> >>Randall Stewart
> >>803-317-4952 (cell)
> >>
> >>_______________________________________________
> >>freebsd-threads at freebsd.org mailing list
> >>http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> >>To unsubscribe, send any mail to 
> >>"freebsd-threads-unsubscribe at freebsd.org "
> >
> >-- 
> >- Alfred Perlstein
> >.- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250
> >.- FreeBSD committer
> >
> 
> ------------------------------
> Randall Stewart
> 803-317-4952 (cell)
> 803-345-0391(direct)

-- 
- Alfred Perlstein
.- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250
.- FreeBSD committer