On Wednesday 13 December 2006 04:49, Daniel Eischen wrote:
On Tue, 12 Dec 2006, Poul-Henning Kamp wrote:
In message <2006...@delplex.bde.org>, Bruce Evans writes:
On Mon, 11 Dec 2006, Daniel Eischen wrote:
It's probably a nightmare in the kernel too. close() starts looking
like revoke(), and revoke() has large problems and bugs in this area.
There is the distinctive difference that revoke() operates on a name
and close() on a filedescriptor, but otherwise I agree.
Well, if threads waiting on IO are interruptable by signals,
can't we make a new signal that's only used by the kernel
and send it to all threads waiting on IO for that descriptor?
When it gets out to actually setup the signal handler, it
just resumes like it is returning from an SA_RESTART signal
handler (which according to another posting would reissue
the IO command and get EBADF).
Even if you have implemented the close() with the interruption, another
thread openning a file still can reuse the file handle immediately,
according to specifications, the lowest free file handle will be returned,
if SA_RESTART is used, the interrupted thread restart the syscall,
it will be using a wrong file, I think even if we have implemented the
feature in kernel, useland threads still has serious race to fix.