Copied from p5p as it seemed kinda relevant.
Dan Sugalski wrote:
Roll on perl6...
Well, besides "Just don't *do* that," any thoughts on how to handle this
properly in p6?
Hmm. I've been half-following the async IO and signals thread in
perl6-internals. The first thing I would say is that if you think there
are portability problems with threads and signals, wait until you get to
play with cross-platform AIO. General received wisdom seems to be that
using multiple threads and synchronous IO is a much easier thing to get
working than trying to use the various difficult-to-use AIO APIs.
That leads nicely onto the next point - signals. Again, the received
wisdom here is that if you are going to use threads and signals
together, you should have a dedicated signal handling thread which does
a sigwait and sets a flag when a signal occurs. The flag would be
polled by the main loop and the signal handler called when it was safe
to do so.
Now I can see that at this point all you speed freaks want jump on me
and tell me how horribly inefficient this additional test would be. I
have only one thing to say to you - get real. One conditional (even if
protected by a mutex) is neither here nor there when compared to the
number of instructions taken to implement a typical perl op, and you
wouldn't do it for every op dispatched anyway. A sensible thing might
to be to get the compiler to emit statement boundary markers into its
output, and use these as points at which you check for and dispatch
signals.
For example, on my platform (sparc), an empty for loop takes about 10
cycles per iteration, a function call to setjmp takes about 10 cycles
and a call to sigsetjmp takes more than 5300 cycles, due largely to the
fact that it requires a syscall and is therefore also an invitation to
the OS to reschedule your process. If you want to worry about
something, worry about that 5300 cycles first. Then worry even more
that setjmp isn't thread safe either.
The upshot of all this is I think perl6 should be mandatorally threaded,
with a mixture of internal threads (signal handler, async IO handler,
garbage collector, whatever), and application threads. Each application
thread would be an entire instance of the interpreter - none of that
crazy mutex madness that doomed the attempt to thread perl5.
Interpreter threads would touch at well-defined points only - the aim
being to avoid mutexes as far as possible, rather than to infect
everything with them. In the degenerate case (existing unthreaded
scripts) there would be only one interpreter instance and therefore only
one application thread.
This has lots of advantages - no changes in behaviour when threads are
used as perl is always threaded, well-defined semantics of how multiple
interpreters coexist and cooperate, system housekeeping can be
modularised and done behind the scenes in dedicated threads etc etc.
The downside is that we would restrict perl6 to only those platform that
supported threads. I'm not sure how much of a restriction this would
turn out to be in practice - how many current perl platforms don't have
threads?
As for AIO - my guess is that faking it up with threads is a much better
bet. After all, what proportion of apps are MT vs AIO, and which is
most likely to be available, well tested and well supported?
Alan Burlison
