This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [MinGW]: Reset/Ignore Thread Interruption for Plain[Datagram]SocketImpl

Bryce McKinlay writes:
 > On Dec 14, 2003, at 5:29 PM, Mohan Embar wrote:
 > > 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,
 > > 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 
 > Selector:
 > "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 
 > invoked."

This is more of a philosophical issue than a technical one.

My take on it is:

Where both gcj and the JDK conform to the spec, but behave
differently, we change gcj to match the JDK.

Where the JDK doesn't conform to the spec, but gcj does, we leave gcj
well alone.

This might be problematic where some applications rely on incorrect
behaviour.  When that happens, we have to make our decision on a
case-by-case basis.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]