Date: Wed, 10 Feb 2010 12:46:46 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Randall Stewart <rrs@lakerest.net> Cc: threads@freebsd.org Subject: Re: Thinking about kqueue's and pthread_cond_wait Message-ID: <Pine.GSO.4.64.1002101232240.13876@sea.ntplx.net> In-Reply-To: <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <Pine.GSO.4.64.1002101202060.13656@sea.ntplx.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 10 Feb 2010, Randall Stewart wrote:
>
> On Feb 10, 2010, at 9:04 AM, Daniel Eischen wrote:
>
>> On Wed, 10 Feb 2010, Randall Stewart 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?
>>
>> Please don't mess with the pthread_ API like that :-) If you
>> really want to munge them together, see my email to you a few
>> weeks ago last time you brought it up.'
>
> If I remember right your email was basically don't do it... I will
> go dig through the archives and re-read it all.
No, it was to add an interface or two to the kqueue/kevent API, not
to modify the pthread_ API (which shouldn't know anything about
kqueues).
I really think the OS is already given us the tools we need to
do the job simply enough. You can easily use a pipe, socketpair,
or EVFILT_SIGNAL to wakeup a thread stuck in kevent(). You can
additionally use a mutex to protect data shared between thread
waiting in kevent() and other threads.
I don't see what problem this is trying to solve and I think
whatever solution you come up with involving mutexes/CVs is
not going to be any simpler and may even be more complex and
messy. Mutexes and CVs are userland library thingies, not
kernel entities. Yes, the umtx is a kernel entity, but it
alone does not give you mutexes and CVs. So when you want
to mix kqueues and mutexes/CVs, you are involving another
userland library and this is what makes it messy.
--
DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1002101232240.13876>