Hey guys,
Is it possible to have a worker thread send data out a TCP connection while another thread is waiting using using select() on that same connection?
If not, then what is the correct way to maintain a connection, react to incoming data, and send data over a TCP connection?
Thanks for any insight.
Yes, that is one way of handling things.
Your terminology is just a bit off though. The select() is listening for connection requests on the port; there is no connection.
Isn't that what accept is for? select() can indeed wait until an existing socket is ready to send or receive...
I'd try to avoid a race condition like waiting for a socket to become ready for writing while writing to it.
I think that Corona has it right. At least that's my understanding.
So the real heart of the question is whether or not a single socket can be used for blocking and sending at the same time. Has anyone attempted this? We are having strange issues when doing it, like seg faults.
A segfault would almost certainly be a bug in your code. Please post a minimal example that still segfaults.
Yes, it's my brain that is off this week. (grumble). I assumed the OP wanted to listen for additional connections while using the established ones.
After select() returns without error you pass the socked handler to accept(), accept() will return a new socket ONLY for that particular connection/session, the first socked is free again to be handled by select() and loses relation with previous client. You should not write or read anything on the main socket.
We're doing that without any problem. We have one thread that blocks on the socket waiting for the server to send data; while another thread might independently send some data to the server. Works like a charm.
As mentioned By Coronna688, the best way for you to identify the problem (and for us to help you) is to write a minimalistic example - that compiles and show what your problem is.
Good Luck,
Lo�c
I have a feeling that you have no idea what you are talking about. The SOCK_STREAM socket that you listen on is handling session queue. When you call accept() you end up with completely different socket to handle actual I/O for the TCP session.
This is supposed to be your reply to my answer, I guess?
If you read my answer carefully, you'll see that I just told the OP that it is not a problem to write/select at the same time on the established connection (the socket you obtained as result of accept).
writing on the listening socket doesn't make any sense, so I discarded this possibility. Though I couldn't absolutely sure from OP answer that s(he) not trying to do that.
Cheers, Lo�c.
Why would you use select() on established connection when recv() is already blocking?
When for instance blocking forever is not acceptable, and a timeout is needed... This is a classical requirement for real-world systems, and select() is one of the many possible ways to fulfill it.
Cheers, Lo�c
recv() is capable to timeout as it uses select syscall internally and timeout is configured with setsockopt(), putting one more select call in front just adds overhead.
Quoting yourself: I have a feeling that you have no idea what you are talking about 
Not all systems support SO_RCVTIMEO, so this last statement obviously doesn't make sense...
Your reasoning is excellent, but your basic assumptions are off. If you read carefully my posts, I just mentioned that it is possible to block on a socket, while sending data, since TCP is full-duplex. Nothing more, nothing less.
And even if people err (I personally do), I don't feel the need to treat them "maroons that have no idea about what they're talking about". We're all here to learn, and this can be achieved in a respectful way.
Just my 2c,
Lo�c
Sockets are also not available on EVERY system, does not mean you should not use them. The option is available on Windows, Linux and BSDs, haven't checked more.
Go check the POSIX specification for socket's options. The STANDARD said so.
---------- Post updated at 05:11 AM ---------- Previous update was at 04:38 AM ----------
I apologize for my rudeness.
As in abstract implementation goes, it is possible but its not very smart as it is easy to mess up, consider blocking thread unblocks (because it gets data to read) while other thread is sending and starts sending as well, you end up with borked output, or at least there will be a race condition possibility. Smart implementation should use just one thread per connection handler.
You're forgiven.
SO_RCVTIMEO has been standardized with the Single Unix Specification ("aka Unix98"). The POSIX standard that deals with socket is IEEE Std 1003.1g-2000 ("aka Posix.1g") and AFAICS setting timeout on socket is not mandatory.
A decade ago, select() was considered the most portable way to achieve timeout; as there were many unix-like systems that had sockets, but not SO_RCVTIMEO. Now 13 years after Unix98, I expect most modern system to support this option. Even if you don't work on a "archaic system", you may find this pattern in older code.
Beside this point, there might be situation where select() - or rather the modern version poll() - makes more sense. Like: variable timeout depending on the expected answer length, when the polymorphic aspect of the descriptor is used...
I checked the Linux/FreeBSD kernel source. For Linux, you're right: recv() call the poll() syscall internally. For FreeBSD, both select() and recv() are built on the tsleep() syscall.
Cheers, Lo�c
There's modern systems like OSX where poll() doesn't work on a variety of things like terminals.