>Depends on what you want to do. For files at least, I'd want the file
>descriptor to be closed, period. This means that if thread A reads from the
>modem and thread B wants to close things down, thread B close()s the file
>and A notices this somehow (EOF, signal, whatever).
I think we agreed (I did :) that the situation at hand is a programming
error anyway, and we should only be concerned that the kernel does not crash.
Thread A sits in read() while B closes the file. If the read() returns
later, the next read() will result in EBADF, so A is notified. When it
doesn't return, too bad. A is stuck. It was a programming error anyway :)
Defining EOF,signal,whatever behaviour for this case would mean new
complexity to the system calls, and that's contrary to the whole clone() idea.
Hmm, does anybody know the Posix asynch IO interface good enough to tell
how an asynch read would behave if the underlying fd were closed?
IIRC the behaviour is unspecified.
>Memory mappings can of course use counters, but you'd have to add the
>appropriate unlock calls to every procedure which uses verify_area.
>This is probably something that should have been done from the beginning...
Is there any problem with memory mappings? They seem to work from inodes,
not from filps, so they should be safe anyway.
bye
Patrick