Re: Demystifying Continuations

[ryan daum <address@hidden>]

On Thu, 21 Mar 2002, David Simmons wrote:

> -- SIDE NOTE ON NATIVE THREADS --
> Further noting that since a continuation is really a capturing of state
> both "for" and "within" a given execution context, there are technical
> issues with creating continuations on native OS threads.

This brings up a selfish question in relation to the interpreter/vm I am
writing as my own personal project
(http://darksleep.com/twiki/bin/view/Main/Poe), which I would love to hear
people's more-expert implementation ideas in relation to. -- I have my own
"scheduler" overtop of the virtual machine which maintains, as you
describe, a chain of active and inactive stack frames and the messages
(send and reply) that link them.  The scheduler can (and does) suspend
these "events" in the queue if they use too many "ticks" (opcode
executions...).  So, in a way, I have my own "threading."

However, interacting with nativecode, or routines which I cannot "suspend"
or manipulate the stack of has become an issue -- I wish to bind a whole
series of natively compiled method objects to my basic types, to provide
type-related services, and I wish to be able to let any programmer build
such modules through loadable DLL packages.  The problem comes in that
although it is entirely feasible to call _into_ a nativecode method block
it is entirely impossible to call "out" of it, back into the scheduler and
still maintain the call sequence, since the scheduler has now lost control
of the thread of execution, unless I throw nativecode methodblock
execution into another OS thread/task entirely ... and this seems
incredibly baroque and inefficient, as well as requiring the care and
concern for lock and resource management that goes with being heavily
multithreaded (not to mention platform dependency issues)...

Is there an accepted way to handle this kind of situation?  I could depend
heavily on a "top-half" (pre-suspension)  "bottom-half"
(post-continuation) approach but that again seems quite awkward...

Ryan


 >
> Where a native OS thread had significant thread-local state, and
> OS/Process characteristics that a "classic" continuation architecture
> would not include. On systems like Win32 we can use fibers to create an
> efficient continuation architecture [where we can copy in/out stack
> ranges and TIB information].
>
> This allows us to create generally safe continuations that include
> native DLL/EXE library calls within the call-chain.
> -- END SIDE NOTE ON NATIVE THREADS --
>
> -- Dave S. [SmallScript Corp]
>
> SmallScript for the AOS & .NET Platforms
> David.Simmons@SmallScript.com | http://www.smallscript.org
>

____ ryan daum ____________________________________ ryan@techno.ca _________