harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Guilfoyle (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-6326) Socket closure does not signal threads blocked in I/O operations.
Date Mon, 31 Aug 2009 09:19:32 GMT
Socket closure does not signal threads blocked in I/O operations.

                 Key: HARMONY-6326
                 URL: https://issues.apache.org/jira/browse/HARMONY-6326
             Project: Harmony
          Issue Type: Bug
          Components: Classlib
    Affects Versions: 5.0M10
         Environment: Linux 2.6.28 x86_64, as packaged by Ubuntu 9.04.
            Reporter: Josh Guilfoyle
            Priority: Critical

Neither PlainSocketImpl#close nor the underlying OSNetworkSystem call to socketClose attempt
to signal threads that may be blocking in I/O operations on the underlying file descriptor.

Contrasting the Harmony implementation with OpenJDK 6b14 (as packaged by Ubuntu), you can
see that specific attempts are made to unblock threads during the platform's close implementation
on Linux (linux_close.c:NET_SocketClose).

In testing, I have discovered that shutting down the socket's channel which is being waited
upon unblocks any threads.  For instance, if the thread is blocked in a read call then a call
to Socket#shutdownInput will unblock the method.

This bug was first discovered and tested on the Harmony release as packaged with Android 1.5r3
and can be observed on both the emulator and released phones.

For testing, I created an application which spawns a connection thread to read from a public
host, and also a timer to eventually attempt to close the socket and flag the thread as canceled.
 Part of the way through the download, I issue an iptables command[1] on my local machine
to DROP all packets heading to the host of the download which causes the read call to block
up to the socket timeout.  When the thread cancellation is triggered, it is evident both in
my logging and in the prerequisite Thread#join call that the downloading thread is still blocked
in the read call.  If I add calls to Socket#shutdownInput and shutdownOutput in addition to
Socket#close, the blocking thread is unblocked immediately.

I used a similar technique with Sun's JRE 1.6.0_13 which demonstrated that Sun's implementation
unblocks waiting threads without the need to call shutdownInput or shutdownOutput.

My demonstration source code can be found here: 


Though the source code does use Android, the bug can be demonstrated outside that context
with (I believe) any Harmony release to date.

[1] The iptables command I used during testing:

iptables -I OUTPUT -d -j DROP

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message