[concurrency-interest] Interruptible I/O (was RE: enable / disable interrupt

David Holmes dcholmes at optusnet.com.au
Sun Mar 30 00:15:05 EDT 2008


Hi Hanson,

Interruptible I/O was a flawed idea because it didn't take into account what
state the underlying I/O "stream" was left in. It was conceived in terms of
simple reads and writes of N bytes and the InteruptibleIOException would
report have many bytes out of N had not been sent at the time of the
interrupt. That works okay at the lowest level of a protocol, but the
information is useless at higher-levels - imagine a HTTP GET request that is
interrupted and all it knows is that 23 bytes were left - 23 bytes of what?
the header, some protocol layer in the packet? what? And if a thread now
tries to read from that same stream what is it going to read? The next
missing byte of something. Basically once you interrupt a thread doing I/O
on a stream then the stream should be considered unusable.

Given that the real aim of interruptible I/O was for threads to unblock from
calls that weren't going to get serviced, there were better/safer ways to do
that:
- timeouts on the underlying socket operations
- closing the socket/stream

(Though for a long time there were issues - and maybe still are - because
Java didn't expose the APIs to set timeouts in all places that you'd want
them. And the close() semantics took some effort to get right on all
platforms.)

When the NIO API's were defined for InterruptibleChannels they took the same
approach: interrupt means close. So interrupting a thread blocked on an
InterruptibleChannel closes the channel. That way there is no issue about
what state the channel is left in.

I know this crops up from time to time. One of the most detailed write-ups
occurs in the evaluation for bug 4154947. In other bug reports you'll see
that this was eventually deprecated in the sense that Sun were never going
to try to implement it or support it. Even so, it is only in JDK 7 that
interruptible I/O will be disabled by default on Solaris. Things change over
time, particularly in relation to OS support etc. It turns out that its
fairly easy on Windows to allow a thread to be unblocked while waiting on
IO - you just do a waitForMultipleObjects on the IO handler and an interrupt
Event object. But that doesn't address the underlying issue with the state
of the stream.

Also as you note, nothing else gets you out of a blocked I/O operation, not
even Thread.stop - another reason the deprecation of Thread.stop was no
great loss.

Cheers,
David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Hanson Char
  Sent: Sunday, 30 March 2008 1:42 PM
  To: dholmes at ieee.org
  Cc: concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] enable / disable interrupt


  Hi David,


    But interruptible I/O was a
    flawed idea that was only ever (partially) implemented on one platform
(and
    caused a lot of grief).

  Why is interruptible I/O a flowed idea ?  Could you point me to more
information on this ?  Recently I realized there is no other way to
explicitly unblock a thread blocking on a socket read besides from another
thread, besides closing the underlying socket.  Not Thread.interrupt() or
even Thread.stop() would help in such scenario, potentially creating a black
hole of resource leakage.  I have been contemplating along the line of
implementing a form of general interruptible network I/O using such
socketing-closing technique, regardless of whether the socket was created
with any so_timeout a priori.

  Hanson Char






-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080330/05505e85/attachment.html 


More information about the Concurrency-interest mailing list