directory change notification patch

[Jeremy Allison]

On Sat, Mar 26, 2005 at 12:17:49AM -0500, Derrell.Lipman at UnwiredUniverse.com wrote:
> Derrell.Lipman at UnwiredUniverse.com writes:
> 
> > Mark Weaver <mark-clist at npsl.co.uk> writes:
> >
> >> - smbd code assumes that (change notify) signals are delivered via EINTR
> >> when calling select.  Since notification polling is disabled in the present
> >> code if kernel change notification is active, the assumption would seem to
> >> be that the notification is reliable.
> >
> > and
> >
> >> In summary (and I probably should have said this at the start), the change
> >> is simply a fix to what appears to be the intended mechanism of signal
> >> delivery, which is currently broken.  You can test this quite easily for
> >> change notify by having a script change a directory repeatedly and
> >> observing that "kernel change notify on" is missing from the logs on
> >> occasion.  Since change notify is one-shot, this is somewhat of a disaster.
> >
> > These two statements may be at odds.  If there is supposed to be a one-to-one
> > correspondence between a change notification and a signal, EINTR does not
> > guarantee that.  Multiple signals can be merged into a single signal if they
> > occur before being caught by the application.  This is why Linux added "real
> > time signals" which may be queued, and the number of generated signals is
> > guaranteed to be what the application receives.  Is a one-to-one
> > correspondence between a change notification and a signal necessary?
> 
> Ugh, re-reading this again, I was really unclear.  It must be time to go to
> sleep.  EINTR, of course, has nothing to do with _which_ signal caused it.
> The concept still applies, though, if the signals which are generating the
> interrupt are normal Unix signals.

Well it's definately time to go to sleep for me, but I'm going
to check any logic changes very carefully before making any changes
to this code. Remember this particular part of the code has been tested
for a long time on a *lot* of systems. I never change the select code without
long and careful testing.

Also remember, the kernel change notify code explicitly uses POSIX real-time
signals on Linux, which are queued and not lost.

So we should be able to match any change with a signal - they are
not merged in the normal UNIX way. This was taken into account when
this code was written.

Jeremy.