On Thu, 25 May 2000 [EMAIL PROTECTED] wrote:
> On Thu, May 25, 2000 at 12:31:57AM -0400, Alexander Viro wrote:
> > ObNotifications: IMNSHGutFeeling it _screams_ "wrong interface chosen".
>
> You feel that signals are too heavy-weight? You may be right. What
> interface would you prefer? A remember-missed-events poll? /dev/imon?
> /proc/self/notifiers...? :-)
SIGPOLL is basically a remnant of misguided Missed'em'V attempt to do
async IO. Bears all usual Missed'em'V elegance... Seriously, folks, all
signal-related functions have extremely kludgy semantics - signals were
fundamentally _not_ supposed to be used as a basis for async IO.
/dev/imon... Yuck. You mean, system-wide pipe a-la, excuse me, SGI?
/proc/self/notifiers... May be interesting.
Let's see - what do we actually want? Something that would repeatedly
notify us about the changes in object. Preferably without duplicates
(otherwise rm -rf will spam the hell out of the kernel). Moreover, it
shouldn't be "send and forget" - otherwise we are in for interesting
races. One more thing: we may want to have separate "channels" - for
different sets of objects. So what we actually nees is a (set of objects
being watched + channel for getting notified). Reading from such channel
should deliver us the set of object that changed since the last read. Then
select() on that channel will do what we need. Notice that we have an
ideal mechanism for obtaining the set of opened files - it's currently
used in AF_UNIX sockets.
So it looks like a directory where we can create (see below) and
unlink() - that would add/remove the objects being watched + an AF_UNIX
socket. We also want to be able to look at the set of objects, right? I
mean, by plain old ls -l on that directory. Fine, so let's do the
following:
symlink() in that directory - adds an object.
unlink() - removes.
bind() on the directory/notifier - normal bind().
recvmsg() - get the SCM_RIGHTS message containing everything that
changed since the last message (and, as usual for SCM_RIGHTS, install the
descriptors into your fd table and put their numbers into your buffer).
select()/poll() on that socket - as usual.
Looks like a very simple filesystem for me... Allow users mount it
on the directories they own and you are done. Moreover, it allows
processes to cooperate - several (un)register, one watches. It also allows
to have several sets you want to watch - no magic needed. It gives you
usual control over the access - plain and simple permissions.
Comments?
