On Wed, Oct 18, 2006 at 03:52:50PM +0200, Robert Schuster wrote:
> Hi all,
Hi!
> the title looks like fun, eh? :)
Not really, if you spend some time with that stuff. ;)
> In an attempt to get gnu/testlet/java/net/ServerSocket/ReturnOnClose to succeed
> on Cacao with the new an shiny VMChannel implementation I found out the Cacao's
> Thread.interrupt() does not cause blocking system calls to be interrupted. A
I found an even nastier problem (after debugging the whole day): If
one thread is blocking in a system call on a file descriptor (in my case
it is `accept`), and another thread closes this file descriptor, the
blocking call does not return.
What's even worse in the case of accept: The same file descriptor may
later be opened by another thread, for example by creating a socket on a
different port. Now an accept on this "new" file descriptor (the same fd
number) is started. Big problem: The _old_ accept call is still running,
and it is a race which of the accept calls will return when a connection
comes in.
This happens with CACAO if you run mauve tests like this:
cacao Harness java.net.HttpURLConnection
The testlet gnu.testlet.java.net.HttpURLConnection.responseCodeTest
creates a server that returns "505" responses. The ServerSocket is
closed at the end of the test, but the following test
(gnu.testlet.java.net.HttpURLConnection.responseHeadersTest) gets the
same fd for its server, and since the old accept is still running, it is
a race about whether the test gets a "505" or a "200" response,
**even though the new server uses a different port**.
BTW google told me, that we are not the only ones having this problem:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4344135
This is really a nasty case. I fear it requires special infrastructure
for `close` and blocking system calls, so the blocking threads are
interrupted, and the file descriptors get invalidated.
-Edwin
