kqueue giant-locking (&kq_Giant, locking)

[Brian F. Feldman]

Garrett Wollman <wollman at khavrinen.lcs.mit.edu> wrote:
> In article <200404170330.i3H3Ul0t032543 at 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 at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\