On Sat, 29 Aug 1998 15:49:05 +0100, Jamie Lokier
<lkd@tantalophile.demon.co.uk> said:
>> May I suggest that instead of a completely new API, you consider
>> extending the existing FASYNC and poll() functionality to cover regular
>> files and directories? There's no reason why the existing APIs can't
>> deal with these cases, and with F_SETSIG, we also have a convenient way
>> of letting the user find out exactly what happened when the signal
>> arrives.
> For FASYNC, I think we'd need another ioctl to say "if this
> directory/file is modified, or this directory's inodes are modified,
> that now counts as pending I/O for SIGIO purposes".
Not really. The FASYNC semantics are completely undefined on
non-blocking files. We are quite at liberty to define our own
semantics, such as defining SIGIO delivery when the inode gets
modified.
> I do think poll() is the ideal place to add the extended functionality,
> not select(), as poll() has scope for new types of events to be added.
> Also, programs which use this mechanism would like to know at compile
> time if it's supported. Relying on unusual behaviour of select() on
> directories would mean these programs compile fine on other OSes or even
> older versions of Linux, but don't work properly.
Yes. Any program using these features is going to have to check for
them at run-time anyway, because even if you compile under a kernel
which has the functionality, there's no guarantee that the program won't
get run under an older kernel.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html