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

>>>>> "JT" == John Tobey <[email protected]> writes:

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

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

having the default callback names in caps is a good idea. but you can
always override them with any others including lower case names.

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

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

that is not what i meant (i think). what i seem to be trying t say is
that only one binary of perl gets built. threads are enabled by some
pragma which will include any thread support from a precompiled
dynlib. the pragma also enables shared vars to be used and that will
affect the compilation of that perl code. whereas i don't think there
should be any impact on a single default perl thread as it won't share
anything. 

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

please explain i-threads.

  >> =head2 Continuations
  >> 
  >> <FILL THIS IN>

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

i don't know what continuations are. they sounded flow controlish so i
just put in a slot for them here. if they don't belong, out they
go. coroutines are closely related to callback dispatching IMO,
especially if we allow their declaration with some prefix as someone has
proposed.

uri

-- 
Uri Guttman  ---------  [email protected]  ----------  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  -----------  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  ----------  http://www.northernlight.com