Jump to content
  • Advertisement
Sign in to follow this  
jregan

pselect sockets question

This topic is 4525 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

Hello, I am working on a socket program where the program must be able to monitor for incoming requests, but also be able to write requests to each connected client based on received messages. This has led me down to a choice between using the "select" system call to set up file descriptor lists for those available for reading and those available for writing and the "pselect" call. What concerns me now is that I have read up more on "pselect" and I am still a bit confused about its properties with regards to signal-handling. My question is this: In the examples for pselect, it's indicated that it serves the same purpose as doing a sigprocmask call with some particular signal around a regular call to select. How I read it is that I guess the client can send signals to the server program along with its messages done via read/write or send/recv. How are those signals passed? Or is it really only talking about signals sent to the server program from the local OS? Any clearing-up of this issue would be greatly appreciated. [Edited by - jregan on March 29, 2006 11:54:05 AM]

Share this post


Link to post
Share on other sites
Advertisement
Signals in the *nix world are transmitted only on a local machine. They won't propagate between client and server machines over a network connection. The signal used in pselect() will fire only on the machine that makes the pselect() call.

Hope that adds some clarity [smile]

Share this post


Link to post
Share on other sites
Yes thank you that does clarify. So "pselect" is really recommended and preferred in programs that use signal-handlers, but is not absolutely necessary to assure that the select method works as planned, correct?

An additional but much related question about select is that if I am using it in a situation where I have file descriptors (sockets) that I wish to use for writing and reading, so they could appear in either one of the lists once a "select" call returns a value to indicate some file descriptor has become available.

Say I have a scenario where I send a message to the server process so it will end up that this socket will end up in the list of those available for reading. I have some other process which will end up in the writing list because it's just waiting, and I am now responsible for reading off of the socket that sent data.

Do I absolutely HAVE to write to this other socket who ended up in the list of those available for writing? I can't remove it from either list because I want to know if it gets written to and becomes available for reading, but I also don't want to have to be handling all sorts of messages from the server just because the socket was available for writing to.

Thank you again for any information on this issue.

Share this post


Link to post
Share on other sites
Yes, that's correct. select() can be used very effectively without mucking around with signals. (For instance, Windows programs have an equivalent to select() via WinSock, and do not need to rely on signals or messages.)

select() only tells you what state sockets are in; it doesn't require you to do anything specific with that knowledge. In fact, it's normal to not even ask select() to check the write capabilities of a socket list when you're just concerned with reading - i.e. just pass a NULL instead of a socket list if you don't care about what sockets are in the writeable state.

A common approach is to do something like this:


Main Loop
App Logic
Network Logic
Read All Incoming Data
Select() for readable sockets
Read from those sockets
Queue up data for processing
Process Incoming Data
Go through internal queue
Process what you can
Remove processed data from queue
Add response data to an outbound queue
Respond to Clients
Select() for writeable sockets
Check queue for data to send on those sockets
Send the data and remove it from the queue

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!