 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2006NIO busywaiting
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? > 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  SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > 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(); } } >> 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 [quoted text clipped - 4 lines] > 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 SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ 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? [quoted text clipped - 22 lines] > > Tom Hawtin > 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 SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ 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. 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. > 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 [quoted text clipped - 4 lines] > > 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 Signature[ 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.