Date: Sat, 17 Apr 2004 01:13:13 -0400 From: "Brian F. Feldman" <green@freebsd.org> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: arch@freebsd.org Subject: Re: kqueue giant-locking (&kq_Giant, locking) Message-ID: <200404170513.i3H5DDgq033705@green.homeunix.org> In-Reply-To: Message from Garrett Wollman <wollman@khavrinen.lcs.mit.edu> <200404170447.i3H4l6Hn021993@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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. In case you didn't notice, kqueues have been horribly broken for years now, and if you go back and look at all the places I've pointed out so far you'll see how those behaviors are broken. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404170513.i3H5DDgq033705>