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

David Holmes dcholmes at optusnet.com.au
Sun Mar 30 18:47:20 EDT 2008


Mark,

Mark Thornton wrote:
> That is true of the nio based operations, but I think it was undefined
> for the original io classes. I seem to remember that there was at least
> one implementation where that approach did not work. Hopefully someone
> will be along to tell us which implementation that was and whether it is
> still true.

Do you mean that "unblocking on close()" was not defined for the original
I/O classes ? That's true - it was a semantic that crept in over time, and
it took a while for it to be applied correctly on all platforms. The history
here is rather torturous to piece together but it's all in the bug parade
somewhere. Certainly "unblock on close()" has been the intended semantic for
a long time now.

Having a seperate thread asynchronously do the close() is not equivalent to
having a timeout on the operation in the first place, but it should unblock
the target - not that it is particularly convenient to setup and you always
have the inherent race-condition between the thread doing the close() and
the thread operating on the stream. The thread may even be unblocked and
processing data at the time the close() occurs. :(

I don't know whether something like NFS even exposes a way to set a timeout.
AFAIK to all the library code in between it is transparent whether or not a
file is local or remote.

Cheers,
David Holmes



More information about the Concurrency-interest mailing list