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
