Fw: Re: Implemented OPLOCK for FreeBsd

[Jeremy Allison]

On Fri, Sep 07, 2001 at 06:15:11PM -0700, Mike Smith wrote:

> This is a fairly Linux-centric view of the situation, for something
> you're arguing should be a standard.

Not really, I'm just mentioning the resource limits I know
about in Linux. HPUX and Solaris have similar constraints.

> It's also not very
> robust-sounding.  (ie. it requires manual intervention and possible
> kernel changes just to deal with possible performance issues.)

What - like the number of simultaneously open file descriptors ?
This is a limit that bites *much* more often in SMB serving
than a realtime signal queue limit would.

> knotes (the kqueue event objects) are allocated on demand, and there
> are no hard limits on them (so that unless you blow out kernel memory,
> you don't have the starvation issues).  As Jonathan also pointed out,
> the sender is synchronously notified of a failure to queue a knote
> as well - I don't know whether Posix.4 signals provide this (I would
> hope so)/

Yep - see my other message. So this really boils down to
POSIX.4 signals have a resource limit tunable, kqueues
don't. Firstly, doesn't that expose the kernel to a DOS
attack if you don't have a per-process limit. If you do,
then hurrah - you've just re-invented the max queue kernel
tunable.

Honestly, these things sound identical to me. The difference
is that one has a standard POSIX API, however much you 
dispise it, and the other is a *BSD invention.

I know you guys won the socket API war, but I think you've
lost this one..... :-) :-).

Jeremy.