Kurt Andersen wrote: > But as far as I understand Arno, he would recommend not going > multithreaded unless absolutely necessary > e.g. lengthy operation which blocks socket I/O.
Yes, I prefer this, it's easier to write and to debug unless there's no need to utililize multiple CPUs for the socket I/O. However I'd move lengthy blocking tasks such as database queries into worker threads (thread pool with a request queue preferably). > > Perhaps a combination of my previous code and a fixed number of > server threads in a "thread pool" could be applied. > When an incoming session is available I could switch between the > available server threads One thread per CPU was OK if you want the socket I/O benefit from multiple CPUs, however lengthy blocking code executed in the same thread context would still block some socket I/O, so moving your lengthy blocking code into worker threads was required anyway. Your current design might not be optimal, however it might be sufficient depending on your needs, it's easier to write anyway. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
