Messages in this thread |  | | Date | Mon, 19 Aug 1996 16:58:41 +0200 | Subject | Re: CLONE_FILES problem. | From | (Patrick Schaaf) |
| |
In linux.dev.kernel you write:
>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
|  |