On 2007-11-14, N. Coesel <[email protected]> wrote:
>>> I would like to issue a bit of warning here and ruin the party
>>> a little :-) I've looked at protothreads myself and decided
>>> not to use them. My main reason is that it will make the code
>>> very hard to maintain because protothreads hide the way
>>> various 'processes' are working together.
>>
>>I don't see how. Can you provide an example?
>
> Look at the protothreads examples and the defines that make up
> protothreads.
I have. It's co-operative tasking with stack-unwinding on
context switches.
> The whole idea is pretty nifty. But I think it is beyond the
> grasp of a lof of programmers and therefore prone to errors
> which are hard to debug.
It may be beyond the grasp of somebody who's never done
anything but Visual Basic macros for a spreadsheet, but
cooperative tasking and stack unwinding are pretty basic
concepts that I'd expect any competent software engineer to
understand.
>>The advantage is that you can structure a protothread as
>>"normal" thread with linear code that waits in multple places.
>>With a simple run() function, you've got to explicitly design
>>and implement a state machine. With protothreads, the state
>
> Yes, but the statemachine will have obvious states and will be
> recognised as such by nearly every programmer.
I guess it's a tradoff between something that's recognizable
but incomprehensible and something that requires a little
education to recognize but is more understandable given a basic
background in programming. I'd choose the latter.
--
Grant Edwards grante Yow! Now that I have my
at "APPLE", I comprehend COST
visi.com ACCOUNTING!!
