directory change notification patch

[Derrell.Lipman at UnwiredUniverse.com]

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.

Sorry.

Derrell