[REBOL] Re: Multithreading with Rebol
From: greggirwin:mindspring at: 17-Oct-2003 11:24
Hi Andreas,
AB> The problem I see w/ coop multi-tasking (and I've implemented two coop
AB> mt server frameworks in REBOL) is that it's a viral, an all-or-nothing
AB> approach.
I agree. One of the biggest issues--at least for me--was getting over
the initial hurdle of realizing that. The other difficulty is that you
often won't realize any benefits in simple applications, so it's
easier just to do things directly in response to UI events and such.
AB> If I have e.g. disk IO, I've to impl a simple file IO in a
AB> coop way, i.e. decompositing it into a state machine w/ small tasks
AB> that preferrably don't block. If I've some computing intensive
AB> algorithm, once more, I've to state it in a coop way.
For me, it's largely an issue of "can I mentally walk through a
sequence of events and visualize how the code is going to behave?" For
me, the cooperative approach, especially combined with FSMs, tends to
make things very clear (and it's portable too! :).
For pre-emptive threading, it's very hard to be sure that you're code
is really correct. i.e. that it will work correctly in all cases. One
reason I find it hard, is that you can't duplicate exact timing or
interrupt scenarios. With a cooperative system, it's predictable and
reproducible. That is, my I/O may block, and cause a delay, but it
won't work "most of the time" and do something potentially *very* bad
when it doesn't work--depending on exactly what you're doing of course.
AB> I'm in no way an expert in the theoretical issues surrounding this
AB> topic, nor am I a REBOL guru. So it may well be that I've missed some
AB> nifty ways to write something that won't require complete changes in
AB> all my coding habits.
I'm not an expert on this either. My bias comes--I think--from how
effectively I've used each technique without having to become an
expert.
For me, the FSM-based stuff I've done for this kind of thing *does*
require a different mindset, and I don't use it for very simple things
(which is most of what we do I'd guess). For more complex things, I
really think it helps me. I have a project with a dynamic UI, that can
request various types of remote data (project keys, etc. via Rugby)
and display incoming MJPG data. At its core is an FSM. These various
event sources feed a queue much like a coop system would work. It may
not be the best solution, but it's easy to understand, reliable, and
performs well. For testing, I can "stuff" events into the queue;
even create entire test scenarios of event sequences.
Of course, what works for me may not work for you. :)
-- Gregg
