26 messages in org.freebsd.freebsd-javaclose() of active socket does not wor...| From | Sent On | Attachments |
|---|---|---|
| Arne H. Juul | Dec 11, 2006 6:47 am | |
| Arne H. Juul | Dec 11, 2006 7:06 am | |
| Achilleas Mantzios | Dec 11, 2006 7:25 am | |
| Achilleas Mantzios | Dec 11, 2006 7:48 am | |
| Kostik Belousov | Dec 11, 2006 9:11 am | |
| Arne H. Juul | Dec 11, 2006 2:40 pm | |
| David Xu | Dec 11, 2006 4:15 pm | |
| Arne H. Juul | Dec 11, 2006 4:25 pm | |
| Arne H. Juul | Dec 11, 2006 4:50 pm | |
| David Xu | Dec 11, 2006 5:04 pm | |
| Daniel Eischen | Dec 11, 2006 5:08 pm | |
| Bruce Evans | Dec 11, 2006 9:54 pm | |
| Poul-Henning Kamp | Dec 11, 2006 10:43 pm | |
| Daniel Eischen | Dec 12, 2006 5:21 am | |
| Kostik Belousov | Dec 12, 2006 5:59 am | |
| Daniel Eischen | Dec 12, 2006 6:24 am | |
| Daniel Eischen | Dec 12, 2006 6:35 am | |
| Kostik Belousov | Dec 12, 2006 6:38 am | |
| Greg Lewis | Dec 12, 2006 11:31 am | |
| Daniel Eischen | Dec 12, 2006 12:49 pm | |
| David Xu | Dec 12, 2006 3:29 pm | |
| Arne H. Juul | Dec 12, 2006 5:59 pm | |
| Bruce Evans | Dec 12, 2006 7:28 pm | |
| Julian Elischer | Dec 12, 2006 11:12 pm | |
| Bruce Evans | Dec 13, 2006 3:28 am | |
| David Xu | Dec 13, 2006 4:10 am |
| Subject: | close() of active socket does not work on FreeBSD 6 | |
|---|---|---|
| From: | Bruce Evans (bd...@zeta.org.au) | |
| Date: | Dec 11, 2006 9:54:12 pm | |
| List: | org.freebsd.freebsd-java | |
On Mon, 11 Dec 2006, Daniel Eischen wrote:
Hacking libthr or libpthread to do this for you is not an option. They would then look like libc_r since all fd's accesses would need to be wrapped. If this needs to be done, it must be in the kernel.
Common sense leads me to think that a close() should release threads in IO operations (reads/writes/selects/polls) and return EBADF or something appropriate. At least when behavior is not dictated by POSIX or other historical/defactor behavior.
It's probably a nightmare in the kernel too. close() starts looking like revoke(), and revoke() has large problems and bugs in this area.
At higher levels, revoke() has no support for either waking up or synchronizing with threads in I/O operations on the revoked file; it only tries to force a close on revoked files that are open, but due to reference counting problems it sometimes gets even this wrong.
At lower levels, I think only the tty driver even partly understands that a device close() can occur while an (other) thread is in another operation on the device. Of course, most revokes are of ttys so the tty driver needs to understand this more than most. It uses a generation count to detect changes of the open instance. It doesn't wake up the other threads and depends on them checking the generation count. The check occurs mainly in ttysleep() where it is fundamentally incomplete on SMP systems -- there is no synchronization, so after a revoke(), threads running on other CPUs just blunder on like they do in other drivers. Giant locking of the tty driver reduces the problem.
Bruce