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?
> Besides, since protothreads offer no time-slicing, there is no
> advantage over making modules each which an 'init' and a 'run'
> function. The run function is being called from main
> repeatedly for every module.
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
machine is implicit in the ordering and control flow of the
source code. I find normal C control flow mechanisms
(if-then-else, while, switch, etc.) far, far, easier to read
and maintain that an explicit state-machine with a giant
switch() statement and assignments to state variables that are
in effect just gotos that allow you to create completely
indecipherable paths through the state machine.
> This setup will make the code much easier to follow and
> maintain.
I haven't spent a lot of time playing with protothreads yet,
but I have spent a lot of time with explictly coded state
machines, and it sure looks like for most tasks protothreads
are going to be a lot easier to write and (more importantly)
read. Perhaps I'll run into problems once I use protothreads
more, but I never look foward to debugging the explicit state
machines required by the init()/run() model.
--
Grant Edwards grante Yow! Is it NOUVELLE
at CUISINE when 3 olives are
visi.com struggling with a scallop
in a plate of SAUCE MORNAY?
