Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > NIO busywaiting

Reply
Thread Tools

NIO busywaiting

 
 
Andersen
Guest
Posts: n/a
 
      01-27-2006

How should I use the OP_WRITE flag when using selectors and sockets? It
tells me when the network card is ready for me to write things to it.
The problem is that I do not always have data to write, so the selector
almost busy waits by returning with OP_WRITE ready indicating that it is
ready to accept data, but I have nothing to write, so it busy waits.

How do I solve this?
 
Reply With Quote
 
 
 
 
Thomas Hawtin
Guest
Posts: n/a
 
      01-27-2006
Andersen wrote:
>
> How should I use the OP_WRITE flag when using selectors and sockets? It
> tells me when the network card is ready for me to write things to it.
> The problem is that I do not always have data to write, so the selector
> almost busy waits by returning with OP_WRITE ready indicating that it is
> ready to accept data, but I have nothing to write, so it busy waits.


Remove OP_WRITE from the set of interested ops. Do not remove it from
the selector because that appears to be a very slow operation (certainly
it was back in 1.4, and I don't know of anything happening to change that).

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
 
Reply With Quote
 
 
 
 
Gordon Beaton
Guest
Posts: n/a
 
      01-27-2006
On Fri, 27 Jan 2006 17:54:52 +0100, Andersen wrote:
> How should I use the OP_WRITE flag when using selectors and sockets?
> It tells me when the network card is ready for me to write things to
> it. The problem is that I do not always have data to write, so the
> selector almost busy waits by returning with OP_WRITE ready
> indicating that it is ready to accept data, but I have nothing to
> write, so it busy waits.
>
> How do I solve this?


When you have data to write, call write() without waiting for
OP_WRITE. If write() fails, use OP_WRITE to determine when the channel
becomes writeable again.

Don't use OP_WRITE as long as write succeeds.

/gordon

--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e
 
Reply With Quote
 
Andersen
Guest
Posts: n/a
 
      01-28-2006
Thomas Hawtin wrote:
>
> Remove OP_WRITE from the set of interested ops. Do not remove it from
> the selector because that appears to be a very slow operation (certainly
> it was back in 1.4, and I don't know of anything happening to change that).


Please explain more. Because it is indeed being *very* slow. I am just
doing interestOps() on the key to indicate interest for writes or not,
otherwise following the standard pattern of:

while(1) {
int num = selector.select();

if (num==0)
continue;

Set selKeys = selector.selectedKeys();
for (Iterator it = selKeys.iterator(); it.hasNext(); ) {
SelectionKey currKey = (SelectionKey)it.next();
/* PROCESS KEY */
currKey.remove();
}
}
 
Reply With Quote
 
Thomas Hawtin
Guest
Posts: n/a
 
      01-28-2006
Andersen wrote:
> Thomas Hawtin wrote:
>>
>> Remove OP_WRITE from the set of interested ops. Do not remove it from
>> the selector because that appears to be a very slow operation
>> (certainly it was back in 1.4, and I don't know of anything happening
>> to change that).

>
> Please explain more. Because it is indeed being *very* slow. I am just
> doing interestOps() on the key to indicate interest for writes or not,
> otherwise following the standard pattern of:


Do you know what it is spending time on? Is it just going around the
loop continuously?

Much the same as Gordon Beaton says in his reply.

Keep your key registered with the selector throughout. However you need
not be interested in OP_WRITE until you find that you can't write any
more. Just write your buffer out, and see if it fails to be copied out.
When the channel wont accept any more writes, only then do you need to
be notified when it is in a state for further writes.

Unless you have data that you can't written at the moment, then there is
no need to be notified of when you can write data. Selecting with
OP_WRITE will immediately return until you fill the relevant system buffers.

Similarly if you couldn't deal with reading any more data (because your
buffers are full, say), then you should not be interested in OP_READ. Or
if all your worker threads are tied up and you can't take another
connection, don't be interested in OP_ACCEPT.

As a rough approximation, you could write your code not to use OP_WRITE
at all (although it will obviously fail nastily when the relevant system
buffers fill up).

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
 
Reply With Quote
 
Andersen
Guest
Posts: n/a
 
      01-28-2006
Thomas Hawtin wrote:

I know this, what I do not know is things related to the technology:
Is SelectionKey.interstOps() the right way to change my interest set?
Should I call Selector.wakeup() to ensure that it actually has any
effect? Otherwise some select() statement might be sleeping
indefinitely, not knowing that I am now interested in some events.

>
> Do you know what it is spending time on? Is it just going around the
> loop continuously?
>
> Much the same as Gordon Beaton says in his reply.
>
> Keep your key registered with the selector throughout. However you need
> not be interested in OP_WRITE until you find that you can't write any
> more. Just write your buffer out, and see if it fails to be copied out.
> When the channel wont accept any more writes, only then do you need to
> be notified when it is in a state for further writes.
>
> Unless you have data that you can't written at the moment, then there is
> no need to be notified of when you can write data. Selecting with
> OP_WRITE will immediately return until you fill the relevant system
> buffers.
>
> Similarly if you couldn't deal with reading any more data (because your
> buffers are full, say), then you should not be interested in OP_READ. Or
> if all your worker threads are tied up and you can't take another
> connection, don't be interested in OP_ACCEPT.
>
> As a rough approximation, you could write your code not to use OP_WRITE
> at all (although it will obviously fail nastily when the relevant system
> buffers fill up).
>
> Tom Hawtin

 
Reply With Quote
 
Andersen
Guest
Posts: n/a
 
      01-28-2006
Thomas Hawtin wrote:

I know this, what I do not know is things related to the technology:
Is SelectionKey.interstOps() the right way to change my interest set?
Should I call Selector.wakeup() to ensure that it actually has any
effect? Otherwise some select() statement might be sleeping
indefinitely, not knowing that I am now interested in some events.
 
Reply With Quote
 
Thomas Hawtin
Guest
Posts: n/a
 
      01-28-2006
Andersen wrote:
>
> I know this, what I do not know is things related to the technology:
> Is SelectionKey.interstOps() the right way to change my interest set?


Yup.

> Should I call Selector.wakeup() to ensure that it actually has any
> effect? Otherwise some select() statement might be sleeping
> indefinitely, not knowing that I am now interested in some events.


Yes, if you are in a different thread from one that might be within
select() (everything becomes a total nightmare if you try multiple
threads simultaneously selecting).

From the last line of the SelectionKey introduction comments:

"In any case, a selection operation will always use
the interest-set value that was current at the moment that
the operation began."

So the current select() is not notified and should be woken (other
activity on the server may mask the bug).

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
 
Reply With Quote
 
Andersen
Guest
Posts: n/a
 
      01-28-2006

My problem seems to be thrashing. select() returns with result 0 and
hence I am busy waiting in a loop, making the computer extremely slow.
Select should be blocking, and returning only if I call wakeup(), yet it
keeps returning with result 0 and I am not calling wakeup() all the
time. What can it be? Also, I do have a try {} catch (Exception ex)
surrounding the select() call, but no exception is thrown.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
NIO with timeouts != NIO? iksrazal Java 1 06-18-2004 02:28 PM
Client socket disconnection event not received on Server socket java .nio Avizz Java 3 09-29-2003 10:47 AM
NIO SelectionKey.interestOps() blocking Dave Roberts Java 0 07-29-2003 07:54 AM
nio classes Roedy Green Java 1 07-29-2003 02:41 AM
a basic NIO Question dhek bhun kho Java 3 07-27-2003 03:50 AM



Advertisments