Thinking about kqueue's and pthread_cond_wait
Alfred Perlstein
alfred at freebsd.org
Wed Feb 10 16:14:48 UTC 2010
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
More information about the freebsd-threads
mailing list