Some thoughts WRT exceptions, events, and threads

[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?

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?

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 ...

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?

Q: Can we use the thread system to run event code (suspend the main
code, run the event handler, resume main code - pthread doesn't seem
to have suspend, while pth(3) has it)

Implementation

Are there any bits already done?

[1] sigaction or signal based. On Win32 the main message loop may also
be a source of such events e.g. WM_CLOSE.
[2] for now, this might be a PerlHash

leo

[K Stol]

(... skipping (1) and (2) ...)

> 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 ...

Is 'the underlying model' the implementation of the OS running parrot (as
oppposed to a self-made system,which would result in Parrot VM being 1
process in the eyes of the OS. So, when preempting the process of Parrot,
all 'threads' in Parrot are suspended (or whatever the official term for it
is)) ?

(I have this idea from the book "VM design and impl in C/C++", Bill
Blunden).
So when the above is true, then that means that Parrot threads will have a
bit different behaviour on each diff. OS (assuming each OS has a somewhat
different impl. of thread scheduling), doesn't it?
Will this give problems, having the same parrot code behave somehwat
differently because of the host OS?

It also remembers me of Java, Java programs having different thread
behaviour when running on different OSs,
is this comparable?

(...)
> leo

Klaas-Jan

[Leopold Toetsch]

K Stol <k_s...@hotmail.com> wrote:
> (... skipping (1) and (2) ...)

>> 3) Threads

> Is 'the underlying model' the implementation of the OS running parrot (as

> oppposed to a self-made system,

On Linux there are many threading libs. E.g. pth (GNU portable threads)
and pthread (POSIX threads). The latter has kernel support and does
preemptive scheduling and can use multiprocessors, while the former is
userland only, one process for all threads.
But I can imagine, that there is also a configure options to select a
threading lib.

> So when the above is true, then that means that Parrot threads will have a
> bit different behaviour on each diff. OS (assuming each OS has a somewhat
> different impl. of thread scheduling), doesn't it?

Yep. But when it comes to multithreading you can't assume the same
behavior on e.g. single or multiprocessor systems anway.

> Klaas-Jan

leo

[John Van V.]

> Yep. But when it comes to multithreading you can't assume the same
> behavior on e.g. single or multiprocessor systems anway.

> leo

Sounds like a user-land implementation should be default then, to guarentee
consistancy across hardware let alone machines. Software targeted for specific
uses can do whatever it wants and I suppose individual corporations would be
better prepared to customize the code.

My hope is that Parrot can support LibOS or ExOS implementations.

John

=====
CXN, Inc. Contact: jo...@thinman.com
President, The Linux Society
http://groups.yahoo.com/group/linux-society
linux society distro -> http://www.thinman.com/eLSD/readme
ThinMan is a registered trademark of CXN, Inc

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com