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.
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