directory change notification patch

[Jeremy Allison]

On Sat, Mar 26, 2005 at 01:46:07PM +0000, Mark Weaver wrote:

> The code for processing kernel change notifications is called from 
> async_processing or from timeout processing.  Now the kernel change 
> notification code (as currently it currently is) ignores the call from 
> timeout processing.  As async_processing is only run when EINTR is 
> received, then in this configuration, if we lose EINTR, the kernel 
> change notification will not be processed until another signal comes  along.

See below as to why we cannot lose EINTR from a kernel change notify
real-time signal.

> My assumption therefore from the way that the code is structured is that 
> 'samba signals' ought to be delivered as reliably as possible.  This is 
> what my change is intended to do.

Ok, I've read your explaination and I don't see why you think changenotify
signals are not being processed.

Whenever a kernel change notify signal has been sent, a byte is written
down the select internal pipe. Thus, the next call to sys_select() will
*always* return -1 and EINTR for every queued real-time signal that was
processed by the change notify signal handler. The signals are essentiall
being queued in the pipe buffer (usually at least 256 bytes, so 256 signals
which should be more than enough for Samba).

A change notify signal is handled by signal_handler() in smbd/notify_kernel.c
- it records the signal and calls sys_select_signal() to queue a write to
the internal select pipe.  We can have as many as 20 outstanding change
notify signals (ie. the next 20 calls to sys_select() will return -1 EINTR).
This is due to the array storage space in smbd/kernel_notify.c. We could
expand this if needed.

#define FD_PENDING_SIZE 20
static SIG_ATOMIC_T fd_pending_array[FD_PENDING_SIZE];

The change notify signals are POSIX real-time, they are queued and
not lost. Can you explain to me how you think a change notify signal
can ever get lost with our current code ?

Remember, the oplock signals use this same mechanism. If an oplock
break signal is lost we're in severe trouble (and may more people
would complain than about lost change notifies). This mechanism (the
current code in lib/select.c with the internal pipe) was created to
ensure *no* real-time signals can be lost - sys_select will always return
-1 EINTR for every real time signal queued.

Please let me know why this logic is in error. I'll need to see
an explicit code-path/timing walkthrough to be convinced.

Thanks,

	Jeremy.