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

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

  JT> On Sun, Aug 06, 2000 at 10:10:39PM -0400, Uri Guttman wrote:
  >> >>>>> "JT" == John Tobey <[email protected]> writes:

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

  JT> Override a method with one with a different name?  This makes no
  JT> sense.  Anything that Perl calls (i.e., the method name is special to
  JT> Perl), should be all caps.  Of course, your packages may define other
  JT> methods, too.

i think that is important to allow. in the callback args you can pass a
method name that will be used instead of the default name for that
callback. i expect most people will not override the default but there
will be cases where it is needed. i see possible cases where an object
has 2 read events pending and want to differentiate them by which method
they callback.

  >> 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> Hmm, it sounds sweet if it can actually work.  Default Perl will
  JT> already be running by the time it gets to the pragma.  Don't you need
  JT> a command-line switch to select thread support?  Is this being
  JT> discussed elsewhere?

i haven't seen any talk about threads since the thread rfc was
posted. all the energy i see (i am not subscribed to all the lists) is
in higher order functions and odd stuff. but flow control is much more
fundamental and will be used by a wider range of hackers. damian said
this stuff isn't sexy and i have to sell it with shorter rfcs.

  JT> In i-threads, data is unshared and invisible to other threads except
  JT> through special interfaces.  I.e., each thread runs its own
  JT> interpreter (the `i') with its own symbol table.  Const stuff like ops
  JT> can be shared to reduce memory footprint.  i-threads have the flavor
  JT> of separate processes and (I think - they're not really supported yet,
  JT> though) fewer problems than raw, native, system threads.

that is basically what the thread rfc said and i agree with it. share on
request is another way to call it. i will be making an rfc on mailboxes
which is a simple way to communicate among threads. many rtos's use such
a thing as it combines a semaphore with a pipe/queue.

  JT> Oh, well I'm not sure, maybe they do belong.  A continuation is
  JT> (abstractly) a copy of the stack.  It's the reverse of eval (or, in C,
  JT> setjmp) in that it lets you back out of a stack frame and later come
  JT> back to continue it, possibly many times.

that is a fancy form of flow control. if anyone can champion it we can
figure out a way to integrate it.

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