(I apologize profusely for the formatting--I'm writing this on a rather primitive
webmail system.)
Disclaimer: this is all from possibly faulty memory, except where it's pure
speculation.
Leopold Toetsch:
I'd like to layout some thougts, which get quite dim, when it comes to
threads. So there are a lot of questions.
1) Exceptions
There are 3 kinds of exception sources:
- hard: e.g. SIGFPE, SIGHUP. They get catched by signal handlers[1]
- soft: internal_exception()
- user: a C<raise> opcode signals a warning or die ...
Parrot does a longjmp(3), constructs an exception object[2], searches
the control stack for a matching exception handler and reenters the run
loop at the exception subroutine if a matching handler was found. If
not, a default catch all handler takes the appropriate action.
pdd06 states:
Exception handlers are dynamically scoped, and any
exception handler set in a scope will be removed when that
scope is exited.
Q: How do we automatically remove exception handlers at scope exit?
-
I believe the intended behavior is that each scope pushes a frame onto the control
stack, so by attaching the handler to this frame, scope exits would automatically
clear the current exeption handlers. We could also attach other dynamic scoping
stuff, such as temp() variables, to this frame; the leave opcode would do it all
automagically.
I could be very wrong on this, though.
Leo:
2) Events
They are generated by e.g. Timer objects or asynchronous IO. They are
kept in prioritized event queues per thread.
Q: When and how do we check the event queue, iff there is something?
-
This is the question I'm haziest on, but I suspect we could check every N iterations
of the dispatch loop (where N may equal 1).
Leo:
3) Threads
The underlaying model are posix threads if available. This implies
that all interpreter data are shared by default. So we'll need per
thread data: interpreter, prederef & JIT code ...
-
Does it? If we have one interpreter per thread, all of that can be hung off the
interpreter data structure. Just because all data is shared at the C level doesn't
mean it is at the Parrot level.
Leo:
Q: How do we separate shared and per thread variables?
On thread creation do we copy all shared PMCs?
Where are these PMCs living, i.e. do we have one common memory
arena_base or per thread?
What about DOD/GC?
-
I seem to remember something about a special "shared data" interpreter and thread, but
I could be wrong.
(remaining bits deleted)
--Brent Dax <[EMAIL PROTECTED]>
Currently cursing Earthlink Webmail
