best way to signal a thread that's blocking on a socket receive

[danieru]

Hi,
I've poked around but can't find anyone talking about this specifically; maybe I don't know the right keywords. At any rate...

I have a thread (I call it the broker thread) that needs to be able to listen for incoming data on a socket stream,and also be able to notice a signal from the managing thread for special tasks (like close the socket, or whatever).

I have a solution that works. Here's some quick pseudo code:

socket.set_so_timeout(100milliseconds)

while (not interrupted by manager thread) {
try{
socket.receive
} catch (sockettimeoutexception) {
//do nothing here...just to break the block on receive
}
}
check and handle message that manager signalled to pickup...


But I'm not satisfied with this solution for several reasons:
1. I don't like the latency that this introduces to responding to the interrupt, up to 'x'milliseconds. I would like the thread to respond immediately.
2. I don't like throwing an exception every iteration; they're expensive
3. If I decrease the timeout, then I'm spending more CPU time looping/exception throwing, if I increase it, then the response time to the interrupt from the manager gets even more sluggish.

That's it in a nutshell. I'm hoping someone can offer some suggestions of a better way to implement this.

As an aside, I'm assuming sockets are thread safe? I've considered running two threads; one that always waits on messages from the manager thread, and the other that's always sitting on the socket receive. If I tried this then sometimes we may get simultaneous read and write on the socket, but I've heard that's ok...don't know for sure though.

Any insight greatly appreciated:)

[mrmatt1111]

i would suggest looking into non-blocking sockets. Instead of having a thread per connection you can have a single thread looking at all sockets.

[danieru]

Hi,
Thanks for the suggestion. I haven't done anything w/ non-blocking sockets so I don't know much at this point, but I'm looking into it. Sounds like it might be just what I need.

[Steve11235]

Non-blocking sockets is the way to go. The only difference is that your reads will often return 0 bytes, which means nothing was there. You will be responsible for making the thread sleep. Don't interrupt the thread, as this could break the socket connection if the interrupt happens at just the wrong time. Use a volatile flag(s) instead to send instructions. Since you control the loop, check the flag(s) each time around, along with doing a read.

[danieru]

Hi, thanks. What you're suggesting makes sense to me, and I've looked into non-blocking sockets and it seems like a good fit! I have a couple of questions: Currently I'm pushing objects across a stream. When using the objectinputstream It blocks until it receives the whole object and then returns the object, but w/ non-blocking sockets and using buffers, it looks like I need to handle the added complexity of identifying when I've received the entire object? As far as I can tell, the non-blocking receive will grab what's there, which isn't guaranteed to be the entire object, so I would need to have a temporary storage where I keep appending the buffer contents (as they come into the socket) until I find the end of the object, at which point I can take the object and use it, then empty the temporary storage. Is this sounding correct? Are there any other things I need to consider that I'm missing? What is the best way to identify when I've received the entire object?

[Steve11235]

Write to an internal stream and let the object stream read from that. The object stream should still block.