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