Fw: Re: Implemented OPLOCK for FreeBsd
jra at samba.org
Fri Sep 7 19:58:36 GMT 2001
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
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..... :-) :-).
More information about the samba-technical