Re: RFC 47 (v1) Universal Asynchronous I/O

On Sun, Aug 06, 2000 at 04:14:32AM -0000, Perl6 RFC Librarian wrote:
> If cb is an object then the default 'readable' method on $obj is invoked
> when data could be read from the socket. You can select your own method
> with the 'method' argument. Similarly for the timeout, it calls the
> 'read_timed_out' method by default if that is triggered before any data
> is readable. By using well chosen default method names which makes them
> easy to use, we make asynchronous I/O calls much simpler and
> consistant.

For consistency with Perl's use of callbacks for other purposes, the
method names should be all caps.

> I propose that Perl6 threads be in the core (not a compile time option)
> and with a proper design and implementation will be effective and
> efficient.

Huh?!  You mean, allocate mutexes and lock and unlock everything when
you know you don't want threads?  Making threads the default
configuration is probably what we want instead.

> I agree with the idea of RFC 27 that the best map of Perl and threads so
> far is one complete Perl interpreter per thread.

Oh, I guess this partly answers my last question.  You mean ithreads.
I think we may see non-i-threads, too, in a bit nicer form than 5.005
had.

Note to internals people:  In addition to the async check function
used in the op dispatch loop, we will need a beefier version for
long-running foreign code that properly transitions the thread into
Perl mode and back.

> =head2 Continuations
> 
> <FILL THIS IN>

Hmm, I haven't given this much thought, but are continuations really
async-ish?  They're not in the system/asm-level way that signals, I/O,
and thread switches are.  Coroutines, on the other hand, are probably
amenable to the kind of interface you propose here.

-John