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] Commented: (HARMONY-6326) Socket closure does not signal threads blocked in I/O operations.
Date Mon, 31 Aug 2009 23:36:32 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749676#action_12749676

Josh Guilfoyle commented on HARMONY-6326:

Further study shows that shutdown(socketfd, SHUT_RDWR) also causes a blocking recv call to
immediately return 0 (indicating an orderly shutdown), which obviously breaks out of the read
loop.  Could the solution really be as simple as unconditionally adding shutdownInput and
Output to PlainSocketImpl#close?

Oddly enough, in exploring the rest of Harmony I found SocketHttpClientConnection#close calls
shutdownInput and Output.  Perhaps this was a band-aid to fix an issue that was once thought
to be specific to HttpConnection?

> 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: 
> http://github.com/jasta/harmony-socket-bug/tree/master
> 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