Date: Fri, 22 Jan 2010 10:49:44 -0800 From: Randall Stewart <rrs@lakerest.net> To: Daniel Eischen <deischen@freebsd.org> Cc: freebsd-hackers@freebsd.org, Ivan Voras <ivoras@freebsd.org>, Jilles Tjoelker <jilles@stack.nl> Subject: Re: Greetings... a patch I would like your comments on... Message-ID: <72CD3F66-1428-4876-BE35-6651417C5BC0@lakerest.net> In-Reply-To: <Pine.GSO.4.64.1001221236390.5324@sea.ntplx.net> References: <AD99639C-0DC6-4C4C-B945-A8BD23D6DF8E@lakerest.net> <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> <hjcgfv$100$1@ger.gmane.org> <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> <20100122172525.GA37884@stack.nl> <Pine.GSO.4.64.1001221236390.5324@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel:
Well it may be ugly, but it gets even
uglier on how you have to pass the mtx down
to the kernel with the cond wait variables...
One can do it.. but it will take some additional
changes to the kevent structure which breaks the ABI... which
I was not going to venture down that path :-)
Hmm I suppose one might be able to abuse udata. Right
now the incoming "value" is in the data (the value that is checked
before putting you on the umtx sleep queue).
We could, pass the mtx into the "udata" field but this rather breaks
the definition of udata:
"Opaque user-defined value passed through the kernel unchanged"
Now I suppose if you placed the MTX pointer there that you are
NOT exactly changing it ... but you WOULD be changing the value
of it (as you unlock the mutex)..
I will work on getting this first set of changes into the kernel. If
we don't abuse udata, then the only choice would be to add some
additional
"data" element.. or maybe as Ivan suggested a "blob" which would
still mean an ABI change since you would have to include a size in
the blob... hmmm unless we did "data" is a pointer and flags is the
size.. But this really seems hackish .. sigh ..
R
On Jan 22, 2010, at 9:58 AM, Daniel Eischen wrote:
>>
>
> This is ugly from the userland point of view -- if you need
> this, I would encompass everything in a kq event object
> thingie. As in:
>
> /*
> * Create an object containing everything you need to wait
> * or signal kqueue events.
> */
> kq = kqueue();
> kq_obj = kq_create(kq, ...);
>
> kq_lock(&kq_obj);
> while (!P)
> {
> /* Atomically unlocks kq_obj and blocks. */
> nevents = kq_wait(&kq_obj, ...);
>
> /* When you wakeup, kq_obj is locked again. */
> }
>
> do_work(); /* Wouldn't you want to unlock before this? */
> kq_unlock(&kq_obj);
>
>
> /* From another thread, you could do: */
> kq_lock(&kq_obj);
> if (kq_waiters(&kq_obj) > 0)
> kq_signal(&kq_obj); /* or kq_broadcast() */
> kq_unlock(&kq_obj);
>
>
> --
> DE
>
------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?72CD3F66-1428-4876-BE35-6651417C5BC0>