Date: Sat, 17 Apr 2004 11:59:50 -0700 From: Peter Wemm <peter@wemm.org> To: freebsd-arch@freebsd.org Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Subject: Re: kqueue giant-locking (&kq_Giant, locking) Message-ID: <200404171159.50311.peter@wemm.org> In-Reply-To: <200404170513.i3H5DDgq033705@green.homeunix.org> References: <200404170513.i3H5DDgq033705@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 16 April 2004 10:13 pm, Brian F. Feldman wrote: > Garrett Wollman <wollman@khavrinen.lcs.mit.edu> wrote: > > In article <200404170330.i3H3Ul0t032543@green.homeunix.org> you write: > > >I can't imagine a well-designed applications has kqueues of > > > kqueues. > > > > I can in about five seconds' worth of thought. > > > > Suppose you have library X. It accomplishes some task > > asynchronously (it doesn't matter what or how), and provides a > > descriptor that the calling application must poll for completion. > > Now use that library into an application that has its own event > > loop. > > > > This is one of the specific motivating examples behind doing kqueue > > rather than simply extending poll() or select(). Please go and > > read the papers before you continue down this path. > > Contrived. Let's see one. There won't be any -- they will be using > threads, not kqueues, because threads work on more than one system. Actually no. We do this sort of nesting at work. And we don't use threads. Its not a contrived example. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404171159.50311.peter>