Thinking about kqueue's and pthread_cond_wait

[Randall Stewart]

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)