Re: Directory-change notification (was Re: Desktop)

[Owen Taylor <otaylor redhat com>]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > is that POSIX RT signals have a nasty API, and in fact, systems of
> > messages from the kernel will inevitably have a nasty API, simply
> > because you can't allocate an arbitrary-sized queue in the kernel and
> > have to to deal with the possibility of overflow.
> > 
> > A possibility that occurs to me for dealing with that problem of
> > message-queue overflows is to have a user-space daemon that is
> 
> We already handle queue overflows. You get a signal with no rt info. That
> tells you 'something happened, your guess what'

Well, yes. I was proposing that a user-space daemon could do the
guessing, encapsulate the signal magic, and provide a compatibility
layer .

Though, actually, it looks very much to me like the queue-overflow
mechanism is broken in 2.3.44, though I haven't actually tested it
with a 2.3 kernel...

The way I understand it, in 2.2.x the way it worked was that if
the queue overflowed while queueing a real-time signal from 
async IO, then it would try again with SIGIO, which would 
simply get marked in the mask of pending signals. 

The comment in fcntl.c is :

			/* Queue a rt signal with the appropriate fd as its
			   value.  We use SI_SIGIO as the source, not 
			   SI_KERNEL, since kernel signals always get 
			   delivered even if we can't queue.  Failure to
			   queue in this case _should_ be reported; we fall
			   back to SIGIO in that case. --sct */

But send_sig_info now tries to queue at least one of every signal,
and if it can't returns an error. So, the SIGIO also gets dropped
on the floor, and, as far as I can see, there is no way of detecting
the overflow at all.

(The amount of documentation on the Linux extensions in this
area makes GTK+ look good, so I might be missing something...)
 
Regards,
                                        Owen