pselect sockets question
Author
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]
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]
Hope that adds some clarity [smile]
Author
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.
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.
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:
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 queueThis topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
