java.nio and SelectionKey.interestOps(int i)

[Kurt Miller]

Great, thank you. A quick test on OpenBSD and FreeBSD shows that
it works as expected on OpenBSD but fails the same as OS X on FreeBSD.

It may be a week or two before I find time to debug it on FreeBSD.
Thanks for the report and test case.

Martin Kihlgren wrote:
> Of course!
> 
> I will attach the code, and here is my results when I run it on two
> different machines:
> 
> On my linux box:
> ------------------------------8<---------------------------
> [0:zond at cthulhu ~/tmp]$uname -a
> Linux cthulhu 2.6.23 #3 SMP Mon Jan 21 10:44:04 CET 2008 i686 GNU/Linux
> [0:zond at cthulhu ~/tmp]$java -version
> java version "1.6.0_0"
> OpenJDK  Runtime Environment (build 1.6.0_0-b11)
> OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)
> [0:zond at cthulhu ~/tmp]$md5sum SetInterestOpsTest.java
> e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
> [0:zond at cthulhu ~/tmp]$javac SetInterestOpsTest.java
> [0:zond at cthulhu ~/tmp]$java SetInterestOpsTest
> Connecter connected
> Connecter sent test1
> Listener accepted connection
> Listener read test1
> Listener wrote test2
> Connecter received test2
> [0:zond at cthulhu ~/tmp]$
> ------------------------------8<---------------------------
> 
> On my OS X Tiger box:
> ------------------------------8<---------------------------
> [0:zond at sharkattack ~/tmp]$uname -a
> Darwin sharkattack.troja.ath.cx 8.11.1 Darwin Kernel Version 8.11.1:
> Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386
> i386
> [0:zond at sharkattack ~/tmp]$java -version
> java version "1.6.0_03-p3"
> Java(TM) SE Runtime Environment (build
> 1.6.0_03-p3-landonf_19_aug_2008_14_55-b00)
> Java HotSpot(TM) Server VM (build
> 1.6.0_03-p3-landonf_19_aug_2008_14_55-b00, mixed mode)
> [0:zond at sharkattack ~/tmp]$md5sum SetInterestOpsTest.java
> e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
> [0:zond at sharkattack ~/tmp]$javac SetInterestOpsTest.java
> [0:zond at sharkattack ~/tmp]$java SetInterestOpsTest
> Connecter connected
> Connecter sent test1
> Listener accepted connection
> Listener read test1
> ^C[130:zond at sharkattack ~/tmp]$
> ------------------------------8<---------------------------
> 
> regards,
> //Martin Kihlgren
> 
> On Wed, Jan 21, 2009 at 4:51 AM, Kurt Miller <kurt at intricatesoftware.com> wrote:
>> Hello Martin,
>>
>> Can you post a minimal test case that reproduces the issue?
>>
>> Thanks,
>> -Kurt
>>
>>
>> Martin Kihlgren wrote:
>>> Hello list!
>>>
>>> I have this problem that I thought maybe you could help explaining.
>>>
>>> I have this application, where a server thread loops around a
>>> select(), and then does stuff to the different SelectableChannels that
>>> pops out from the Selector.
>>>
>>> If something is read from a channel, for example, I send it to a
>>> handler. And if the handler wants to respond in some way, it adds it
>>> to a queue and then does interestOps(interestOps() &
>>> SelectionKey.OP_WRITE) on its SelectionKey. Then it does wakeup() on
>>> its Selector.
>>>
>>> In Sun's java 6 for linux, this works beautifully. The Selector wakes
>>> up, does another select, and finds that suddenly this
>>> SelectableChannel wants to be (and can be) written to.
>>>
>>> In SoyLatte, however, nothing happens! No matter if I wake the
>>> selector up one or many times, it doesn't recognize that the
>>> SelectableChannel and its SelectionKey is interested in OP_WRITE.
>>>
>>> Any ideas?
>>>
>>> regards,
>>> //Martin Kihlgren
>>>
>>