1.4.0 NIO select() behaves different on win32 and linux
3 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Jim_Morris
Posted On:   Tuesday, March 5, 2002 02:51 PM

A SocketChannel that has registered with the Selector showing interest in both OP_READ|OP_WRITE I would expect the select() method to continously return showing that the channel isWritable() until the network write queue fills up (like the select() call in c). This is the behavior I see in Linux. However with Windows I see it return once showing isWritable , then it blocks, and does not show isWritable again, even after a isReadable shows up. Whats up with this? should this behavior be platform dependent? (I am using the release build 1.4.0-b92). e.g. The following code snippet on Linux continously prints out "Got Write" as expected, but on Win   More>>

A SocketChannel that has registered with the Selector showing interest in both OP_READ|OP_WRITE I would expect the select() method to continously return showing that the channel isWritable() until the network write queue fills up (like the select() call in c).

This is the behavior I see in Linux. However with Windows I see it return once showing isWritable , then it blocks, and does not show isWritable again, even after a isReadable shows up.


Whats up with this? should this behavior be platform dependent? (I am using the release build 1.4.0-b92).

e.g. The following code snippet on Linux continously prints out "Got Write" as expected, but on Win32 it prints it once then blocks.


			
while(running){
int n= selector.select();
System.out.println("Returned from select: " + n);

Set readyKeys= selector.selectedKeys();

for(Iterator i= readyKeys.iterator(); i.hasNext(); ){
SelectionKey key= (SelectionKey)i.next();
i.remove();

if(key.isAcceptable()){
System.out.println("Got Accept");

}else{
if(key.isReadable()){
System.out.println("Got Read");
}
if(key.isWritable()){
System.out.println("Got Write");

}
}
}
}
   <<Less

Re: 1.4.0 NIO select() behaves different on win32 and linux

Posted By:   Jim_Morris  
Posted On:   Wednesday, March 6, 2002 01:10 AM

Actually now I understand how the windows semantics works, due to the way the underlying windows WSAAsyncSelect works....



The FD_WRITE event is handled slightly differently. An FD_WRITE message is posted when a socket is first connected with connect or WSAConnect (after FD_CONNECT, if also registered) or accepted with accept or WSAAccept, and then after a send operation fails with WSAEWOULDBLOCK and buffer space becomes available. Therefore, an application can assume that sends are possible starting from the first FD_WRITE message and lasting until a send returns WSAEWOULDBLOCK. After such a failure the application will be notified that sends are again possible with an FD_WRITE message.


I prefer that way, you only get one hit
on the isWritable() it is almost like a completion event
rather than a ready event.

It is much easier to write non-
blocking writes that way. I wish they would make the Linux and other versions work the same way.


Because in order to get the same thing I have running now on Win32 to work
in Linux would be to turn my interest in the OP_WRITE event
on when a write does not fully complete (bytes written < requested bytes), and off again when it
is fully written.

According to the java docs using the interestOps(int)
method to change that interest may block and is implementation
dependent!

Re: 1.4.0 NIO select() behaves different on win32 and linux

Posted By:   Jim_Morris  
Posted On:   Tuesday, March 5, 2002 11:54 PM

Sorry I found this is a known bug, although somewhat misunderstood... on suns bug traq Bug Id 4469394.

basically the bug is that the semantics of the select() operation are very different on Linux and win32.

Re: 1.4.0 NIO select() behaves different on win32 and linux

Posted By:   Jim_Morris  
Posted On:   Tuesday, March 5, 2002 09:20 PM

After some more investigation it appears that selecting on write ready is just broken on win32. I get one pass through saying it is ready, after that it never says write is ready again, even after transmitting data, or reading data. It seems to work fine on Linux.
About | Sitemap | Contact