Hi, On Thursday 29 August 2002 4:37 pm, Luis De la Parra wrote:
I know having a thread dedicated to each connection would be much easier, but since this project is mostly for fun (and to learn!) I'd like to take a "better" approach (note that I am not saying the approach I just described is the best one, but right now it sounds more efficient and scalable to me than the one-trhead-per-connection approach)
The approach may or may no be better depending on the point of view. A few time now I've read that the best time to optimise is later and what you may find you are doing is optimising to early and be doing so making the design overly complex, but I might be guiding you in the wrong direction so let's pursue the current design. Currently you are doing the select in one thread and passing the file descriptors of to another thread for the reading. There are only a couple of ways to put the fd back into the set of fd's being selected on and they all require a new call to select. You've covered two of these yourself, which is to wait for select to return (which could lead to huge delays waiting for activity on another fd) and to force select to return by using a signal. The only otherway is to specify a timeout on the select, but given the three choices I would go for the signal approach. The other option that you may have is to recv in the same thread as the select, it then passes the received data to another thread or threads for processing and goes back to the select. I suspect that most your receives will be serialised anyway as they will in most cased be coming from the same network interface, but I really don't know enough about the low levels of networking and how it's handled by the OS. Given the C APIs I'm fine, but below that is guess work. Anyway if the receives are going to be serialised by the OS of the interface itself, then you may as well do the recv's in the same thread as the select and that way you no longer have to worry about signalling to interrupt the selects. Apart from that I can't think of any nice solutions apart from the one you have already suggested. Cheers, Tom