On Sun, 2006-01-08 at 11:05 -0500, Bob Rogers wrote:
>    From: Steve Gunnell <[EMAIL PROTECTED]>
>    Date: Sun, 08 Jan 2006 15:02:37 +0800
> 
>    Hi,
> 
>    I'm sitting here thinking about cross language calls and what I
don't
>    see anywhere is a prohibition that stops a context from popping a
>    handler or action or whatever that it didn't place there.
> 
>    Is there an intent to prohibit or restrict this kind of behaviour?
> 
> Yes, indeed.  In fact, this is more or less a requirement of the
> existing implementation.  It is not always strictly enforced (see my
> "[PATCH] Restrict clear_eh to handlers in the current context" message
> of a few days ago), but the intent is to make it so.
> 
>    It also seems to me that with coroutines and threads you might have
>    diverging contexts with different active exceptions and actions.
> 
> I am assuming the ithreads model, where there is no sharing of
contexts
> between threads.  I believe that is how threads are currently
> implemented in Parrot . . .

Well I haven't looked at the code but I was thinking along the lines
that Threads and Coroutines inherit their current context from
somewhere ... So which bits can they safely inherit and which bits must
be masked?

Also how does all this interact with the lightweight context that Perl
Blocks need?

>    So is a stack the correct model for this or are we talking a
>    hierarchical chain of contexts each with a stack.
> 
> Yes, it is not strictly a stack, as contexts can have multiple active
> calls.  (The term "spaghetti stack" comes to mind.)  Part II of the
> design will cover this in more detail.  But again, this is already a
> feature of the current implementation.
> 
>    Sort of like the user stack I guess.
> 
>    Cheers,
> 
>    Steve Gunnell
> 
> Actually, I would have assumed that the user stack operated more or
less
> independently of the call chain, but I see it is kept in the context
> structure and not the interpreter.  Hmmm . . .
> 
>                                       -- Bob

Judging by comments about Forth on Parrot this behaviour may have been a
feature of an earlier calling convention where the stack was used to
pass parameters.

BTW I am happy to be told RTFM if there is an M. 8-)

Thanks,

Steve Gunnell


Reply via email to