Luis, IMO, if you have to go through weird hoops or gyrations to make threads work for an application, then one of twop things is wrong. Either the task just isn't conducive to threads, or the approach being taken is wrong, and you need to step back and take a broader look at what you are trying to do. In your situation, you would typically have the main thread with a socket listening on a "well known" port for new connections. It would then create a new socket, bind the new socket to that connection, then spawn a new thread to handle just that socket. There really isn't much overhead to a thread, you can have lots of them. The beauty of this is that the main thread doesn't care about the sockets it has spawned off. If the socket connection dies, the thread just terminates. Since the main socket is only listening for connection requests, it doesn't need to manage the other sockets, let the individual threads do that.
Hi all,
I guess my question is not specific to Boost.Thread, but to threading in general (I'm new at it)... still hope you can help me out, either directly or by redirecting me to the right place (links are very much appreciated)
I'm starting a multi-threaded program using Boost.Thread library: it is a "server", in which a thread loops around a "select" to accept new connections and see when a socket has data to be read, in which case puts the fds in queue from which other threads are taking them out to read the data. The problem I have, is that when a "ReceiverThread" finishes reading the data from the socket, it puts the fd back in the "all connections list", but by this time the other ("main")thread already copied the fds from the list and got into the next "select" loop, which means the socket from which the "receiver" just finished reading, will not be "selected" (monitored) untill the next select loop, which will not be untill a) a new connection comes or b)one of the other connected sockets gets some data that takes makes the main thread return from select.
Russ Poffenberger Engineering Specialist NPTest, Inc. rpoffenberger@nptest.com