> 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.
Personally, I completely disagree. It is very hard to understand control flow when all the state is hidden. You see a 'return' statement -- where does that go? What if you want to log the state of a connection to facilitate debugging? Hiding the state on the stack is not good practice. DS ______________________________________________________________________ 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]