Stack Threads and Exceptions - stackthread.d - qthread.d

[mclysenk at mtu.edu]

>What I do not understand is ...
>Is this complete saving of context really necessary? There is no action
>which is interrupted. If you have only cooperative thread switches, than
>the switches always occurs in a yield function. Isn't it enough to set
>the stackpointer to the other thread and return?
>

Upon consideration, you are correct, I am saving more information than is
necessary.  There is no practical reason to maintain the entire floating point
state.  However, it is still necessary to save the base pointer as well as the
context info in FS, and any other information required by a function call.

>I think of an environment where there is one initial thread (called
>master). It can create StackThreads as slaves. Switching is allway only
>cooperative and is only between the master and his slaves. The master
>thread is also the scheduler. The master has to have a loop where he
>calls the slaves, until all slaves are complete.
>Switching than should be lightning fast.
>
That's the idea.  It's also nice to have 'simple' concurrency for state
machines.  For lots of concurrent state machines, stack threads are a better
system than the traditional approach, which is to use a gigantic switch
statement.  Moreover, they don't have complex synchronization issues like
regular threads, since they are nonpreemptive.

I've actually been using them in several of my school projects, and even with
the very simple scheduler used in the current version, it has greatly simplified
many of my projects.  Once I get some more time, I will conduct a more thorough
investigation of their merits and implentation.

Mik