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