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