Date: Fri, 22 Jan 2010 07:55:47 -0800 From: Randall Stewart <rrs@lakerest.net> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Greetings... a patch I would like your comments on... Message-ID: <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> In-Reply-To: <hjcgfv$100$1@ger.gmane.org> References: <AD99639C-0DC6-4C4C-B945-A8BD23D6DF8E@lakerest.net> <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> <hjcgfv$100$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ivan: A couple of comments... On Jan 22, 2010, at 7:33 AM, Ivan Voras wrote: > On 01/22/10 16:10, Ed Schouten wrote: >> * Ivan Voras<ivoras@freebsd.org> wrote: >>> This is a good and useful addition! I think Windows has >>> implemented a >>> generalization of this (called "wait objects" or something like >>> that), >>> which effectively allows a select()- (or in this case kqueue())-like >>> syscall to wait on both file descriptors and condvars (as well as >>> probably other MS-style objects). It's useful for multiplexing >>> events >>> for dissimilar sources. >> >> NtWaitForSingleObject(), NtWaitForMultipleObjects(), etc. :-) >> > > Yes, I was thinking about WaitForMultipleObjects() - I sometimes > wished I had it in FreeBSD :) > > I think the hackers@ side of the thread is missing the original link > to the patch file offered for review, so here it is: > > http://people.freebsd.org/~rrs/kque_umtx.patch > > My kqueue-fu level is too low to be really useful here but from what > I've read it looks like a logical and even reasonably clean way of > doing it. thanks it made sense to me ;-) > > If I read the comment at filt_umtxattach() correctly, in the best > case you would need an extension to the kevent structure to add more > fields like data & udata (for passing values back and forth between > userland and kernel). I agree with this - it would be very > convenient for some future purposes (like file modification > notification) if the kernel filter could both accept and return a > struct of data from/to the userland. Yeah, more arguments inside the kevent would allow me to add the COND_CV_WAIT* where a lock and condition are passed in as well... But I was hesitant to add more than was already there since doing so would cause ABI ripples that I did not want to face. I plan on committing this to head if I don't get strong "you idiot you did it wrong" comments ;-) R > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org > " > ------------------------------ 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?905EFCFB-7362-4F54-B9E7-69C0B4699A37>