This is the mail archive of the
mailing list for the Java project.
Re: [PATCH] [MinGW]: Reset/Ignore Thread Interruption for Plain[Datagram]SocketImpl
- From: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- To: gnustuff at thisiscool dot com
- Cc: GCJ Patches <java-patches at gcc dot gnu dot org>
- Date: Mon, 15 Dec 2003 10:52:25 +1300
- Subject: Re: [PATCH] [MinGW]: Reset/Ignore Thread Interruption for Plain[Datagram]SocketImpl
- References: <SP6ZTQKFOLMHDB6ZNJLI3YTS3WS05.3fdbe720@p733>
On Dec 14, 2003, at 5:29 PM, Mohan Embar wrote:
+ // Reset and ignore our thread's interrupted flag.
+ // It's not possible to interrupt these sort of
+ // operations on Win32 anyway.
Yuck! Does the Sun JRE really do this?
On both Linux and Windows, believe it ot not. Depending
on which day I wake up in the morning, it either makes
sense or doesn't. On the days it makes sense to me, I rationalize
it by saying: when you've completed the I/O operation in
question, it will never be prematurely (under Sun's JRE);
therefore, an interrupt status of true might mislead the caller
into thinking that the I/O was somehow prematurely interrupted,
which it wasn't.
Yeah, I guess it makes sense if you look at it that way. Oh well.
Like you, I hoped the situation would improve for java.nio, but it
only has somewhat. My channels tests show that under Sun's JRE,
when you interrupt a thread that's blocked under Selector.select(),
you can reliably query the thread's interrupted status immediately
under Linux, but not on Windows.
Surely that behaviour is a bug - it directly contradicts the spec for
"A thread blocked in one of the select() or select(long) methods may be
interrupted by some other thread in one of three ways:
- By invoking the selector's wakeup method,
- By invoking the selector's close method, or
- By invoking the blocked thread's interrupt method, in which case its
interrupt status will be set and the selector's wakeup method will be
If you're interested, take NetTest.java (attached here):
...for a spin under Sun's JRE as well as both pre-patch and
post-patch gcj and see what you think.
Thats a nice test. Have you thought about adapting it into one or more