• Advertisement
Sign in to follow this  

Interrupting select()

This topic is 4740 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all, I have nother question. I've decided to use multiple threads, each thread handling a set of clients. When I say "handling", I mean checking for read notification in a blocking select() call. Now, I need a way to interrupt select(), so I can signal my thread to terminate, or to rebuild the list of socket descriptors (if a new socket is added or one is removed). For my listening thread, I simply have another socket listening only on 127.0.0.1 on a specified port. When I need to interrupt the thread, I connect() to 127.0.0.1 on this port. The thread then sees that it's the notification socket, and it goes off to do whatever it needs to do. However, if I use this method for my new thread (for reading clinet data), there's two ways about it: 1) Have a socket in a listen state, and connect to it 2) Have a connected socket, and send data to it If I go for method 1, then I need to have a unique port for each thread (this might not be much of a problem though. Comments?). Method 2 seems even worse - I need to have a socket connected to some other internal socket (which uses up twice the number of socket descriptors, one for each end), but it means I only need to be listening on 1 port for however many threads I have. I presume that this is a fairly common problem, but I have no idea how to solve it. Any ideas? Cheers, Steve

Share this post


Link to post
Share on other sites
Advertisement
I think I'll just go for method 1 just now. I don't expect to have more than 10 threads running anyway, so that's only 10 ports, which isn't too bad.

Still, it seems a bit... weird. Anyone have any ideas?

Share this post


Link to post
Share on other sites
look into the pthread_cancel function, I think that will help you out.

Related to that, look into pthread_setcancelstate and pthread_setcanceltype

Share this post


Link to post
Share on other sites
Thanks for the reply. Unfortunately I'm using Windows' thread functions (CreateThread()). Also, I don't just want to stop the thread, I need to interrupt it.
For example, if I have a thread with 4 sockets in it, and another user connects, I need to add the new socket to this thread. However, The thread is processing a blocking select() call, and so it won't see that the socket list has been updated until it finishes the select() and re-fills the fd_set. If the current 4 sockets are fairly inactive (or totally inactive), then the select() call will take a long time to complete, and it'll therefore take a long time for the fd_set to be rebuilt with the new socket added. The end result is that the new connection doesn't get any recv() calls processed.

Using one listening socket in the fd_set seems to be working well, but I'd still be interested in hearing how others get around this problem.

Share this post


Link to post
Share on other sites
How would the user connect without the select() un-blocking? Typically, the listening socket would be part of the select(). Are you doing select() in more than one thread?

Under UNIX, you can send a signal to a thread (or the entire process) which will unblock select(). Windows isn't quite as flexible about it, so using the wake-up method is reasonable. Another alternative is to select() with a time-out of, say, 100 milliseconds, and poll for updates and go right back to select()-ing.

Share this post


Link to post
Share on other sites
I have 2 threads - One is accept()ing connections, and one is calling select()ing to call recv(). When a client connects, the accept()ing thread gets interrupted, the new client socket is created, and I add it to my list of sockets to read from. It's at this point that I need to interrupt the thread that's select()ing to call recv(), so I can refresh the fd_set to include the newly added socket.
I suppose I could combine both into one thread, but it makes my design cleaner this way (I have a CSocketServer and a CSocketSet class).

Share this post


Link to post
Share on other sites
Ok, that make sense. I'm not that great in the Windows programming area (as you can tell). Most of the threaded network applications I have seen tend to actually create a thread for each connection made, instead of having one thread go through a list. No idea on how to do it with how you have it structured.

Quick question though, why did you chose the penguin for your thread/post icon, it kinda through me off, as thats why I though you were doing this in Linux.

Share this post


Link to post
Share on other sites
On Unix you would create a pipe and stick the read part of the file descriptor pair in the list for select(). Stopping involves writing 4 bytes into the pipe (just any 'long' value would do). Unfortunately Windows' select() implementation cannot deal with multiple file descriptor types in this manner and you will need to use a WSA event for this. It goes like this (very simplified):

HANDLE l_hEvents[ 2 ];
HANDLE g_hServerStopEvent;

g_hServerStopEvent = ::CreateEvent( NULL, TRUE, FALSE, NULL );
l_hEvents[0] = ::WSACreateEvent();
l_hEvents[1] = g_hServerStopEvent;

//---- This hooks the WSA event to your socket
::WSAEventSelect( hSocket, l_hEvents[0], FD_READ );


for(;;)
{
DWORD l_dwWait = ::WSAWaitForMultipleEvents( 2, l_hEvents, FALSE, INFINITE, FALSE );
if ( l_dwWait == WSA_WAIT_EVENT_0)
{
//---- READ event
}
else if ( l_dwWait == WSA_WAIT_EVENT_0 + 1)
{
//---- STOP event
}
else
{
//---- Doh! Errrrrrr...
}
}

You break the WaitFor...() with the call ::SetEvent( g_hServerStopEvent );

-cb

Share this post


Link to post
Share on other sites
Quote:
Original post by Xipher
Quick question though, why did you chose the penguin for your thread/post icon, it kinda through me off, as thats why I though you were doing this in Linux.
Ah, it's my default post icon (It's also the icon I drew and submitted ;))

I've changed my code to just select() for 250ms, since I was having issues before, and it should be more efficient liek this. A delay of 250ms to a new connection is nothing (Only the connecting client gets the delay), and 250ms is nothing to work about when shutting down the server also.

Thanks for all tge replies.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement