--- David Schwartz <[EMAIL PROTECTED]> wrote: > > > If the context-switching overhead turns out to be too high, then I will > do > > exactly that. But it will mean maintaining state for each connection, > and > > that state will only grow more complex with future enhancements by > myself > > and others. > > Umm, huh?! If you don't maintain state for each connection, how will you > know what to do with the data you get?
Ah, well, I meant that a state machine must store state explicitly, whereas with threaded code the state is implied in the code flow (in effect, the thread system itself is a state machine.) If each thread executes a simple function like "void foo() {A; B; C;}", then the equivalent state machine is simple enough -- it just has to remember whether each "thread" is at step A, B, or C, using an array of state variables or some such. But now throw in a few nested for's, if's, and local data into the above function... well, you get the picture. I could certainly implement my program as a state machine, but that may make my code harder for others to understand/maintain. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ______________________________________________________________________ GNU Portable Threads (Pth) http://www.gnu.org/software/pth/ Development Site http://www.ossp.org/pkg/lib/pth/ Distribution Files ftp://ftp.gnu.org/gnu/pth/ Distribution Snapshots ftp://ftp.ossp.org/pkg/lib/pth/ User Support Mailing List [EMAIL PROTECTED] Automated List Manager (Majordomo) [EMAIL PROTECTED]