Fw: Re: Implemented OPLOCK for FreeBsd

[Jeremy Allison]

On Sat, Sep 08, 2001 at 12:00:17PM +0930, Greg Lehey wrote:

> I think we should be careful not to go too far in the opposite
> direction.  If nobody ever deviates from the standards, we get almost
> no progress (only when the committee can decide).  kqueue promises
> significantly higher performance than real time signals.  Just because
> Samba doesn't need this level of performance (yet) doesn't mean that
> we should choose an inferior implementation.

But there's a difference between an interface that all other
systems (Solaris, HPUX, Linux etc.) have standardized on - POSIX
realtime signals, and one group determined to do something different
seemingly for the sake of it.

> What I'm seeing here, though, is a confusion between interfaces and
> implementations.  Obviously we should support a real-time signal
> interface.  That doesn't mean that the implementation should be the
> same.

I'm not saying the you should drop kqueue, only that it would be better
to have POSIX realtime signals implemented as well (on top of kqueue
if you like, I don't care) and the oplock interface defined in terms
of the standard that everyone supports.

That way, if kqueue is better than realtime signals under the covers
then good for you - you get the best implementation. 

But insisting you will only support kqueue and not POSIX.4 and
application developers be dammed is not helpful and does not
encourage people to port complex code to FreeBSD.

Samba is a special case - we have in interface layer that can
cope with such things. But it's only there because of our
experiments with the IRIX interface. You're lucky that's the
case.

Jeremy.