Alan Burlison wrote:
> 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.
>
> ...
>
> 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
>
Well, I guess this is the time to see all the options we have, so we should
do it now.
As Alan said and I agree, there are portability issues with threads, AIO and
signals. But I believe many of us don't know what they are and also don't
know how to deal with them. Well, I think now is the time to examine it with
real attention so we can possibly go into a direction to a solution based on
real facts, not only on conjectures.
As it seems, we have many options for implementing perl's event loop:
1) use async i/o and implement threads internally, switching the context of
the interpreters.
2) use threads and no async i/o, blocking the event loop when a blocking
syscall is made (how would signals be handled?).
3) use async i/o and system threads where available.
4) not using async i/o or threads. (i don't know) what can we do on
platforms where neither threads nor async i/o are not available?
5) having more than one implementations, for systems with different degrees
of support.
Combining chooses we make on threads, async i/o, signals, threads<->event
loops, and other of those relevant things, we have several options to
consider, that can even affect the language (for example, will perl-level
threads be offered on systems that don't support them but support async
i/o?).
I believe we should not talk anymore about, for example, using aio or not
aio, or using threads or not using threads. I think we should talk about
whole scenarios, for example, using aio but not using system threads, there
is one event loop that does context switching, ... For this to be possible,
we have to list and describe in details what are our options. Some of them I
listed above, but I can't give enough details, I'm no expert on this. Having
a list of our possibilities, we can effectively talk about advantages and
disadvantages (also efficiency) of them.
Other thing to be considered is portability (again, portability of a
scenario, not of aio or threads isolated). I don't really know (or have
access) to many platforms, I think the people on p5p are the ones that can
help better on this discussion. I think we should take facts about the
implementation of aio, threads, signals, ... on these platforms. I think our
target is to make perl6 run in _ALL_ platforms that run perl5 today, but I
actually can be wrong: maybe, given the options, it's decided that platforms
that don't support aio/threads won't have perl6 (???).
As for portability, I think we should try to write down a table with all the
platforms today supported by perl5, with availability (and possible
implementation hints) of aio, threads, (signals?) in all those platforms. I
suggest we work on making a test suite for these features, testing event
loops and operations that can afterwards be used as a base for perl's
kernel. Efficiency benchmarks can be taken here too.
I think those results are the ones that matter for making a decision about
which scenario will be used. I guess that choice is for Larry, but we should
give him enough facts about the scenarios so that the choice is made right
and we don't have to redesign because of portability/efficiency problems.
Branden.
