Chaim Frenkel wrote:
> We may not even need to copy the body.
The nice thing about the "copy body and replace with stub" solution
is that it doesn't impose any costs on threaded subs that don't get
re-bound at run-time. I agree with you that there are lots of
solutions though so re-binding should
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> Adam Turoff wrote:
>> when dealing with threaded bytecode is that the threading specifically
>> eliminates the indirection in the name of speed.
KF> Yes. Chaim was saying that for the functions that need indirection,
KF> they could use stubs.
> > Joshua N Pritikin writes:
> > : http://www.oreillynet.com/pub/a/python/2000/10/04/stackless-intro.html
> >
> > Perl 5 is already stackless in that sense, though we never implemented
> > continuations. The main impetus for going stackless was to make it
> > possible to implement a Forth-styl
Adam Turoff wrote:
> when dealing with threaded bytecode is that the threading specifically
> eliminates the indirection in the name of speed.
Yes. Chaim was saying that for the functions that need indirection,
they could use stubs. You don't need to guess in advance which ones
need indirection b
> "AT" == Adam Turoff <[EMAIL PROTECTED]> writes:
AT> On Tue, Oct 24, 2000 at 10:55:29AM -0400, Chaim Frenkel wrote:
>> I don't see it.
>>
>> I would find it extremely akward to allow
>>
>> thread 1:*foo = \&one_foo;
>> thread 2:*foo = \&other_foo;
>> [...]
>>
>> copy the &foo bod
On Tue, Oct 24, 2000 at 10:55:29AM -0400, Chaim Frenkel wrote:
> I don't see it.
>
> I would find it extremely akward to allow
>
> thread 1: *foo = \&one_foo;
> thread 2: *foo = \&other_foo;
> [...]
>
> copy the &foo body to a new location.
> replace the old
> "JvV" == John van V <[EMAIL PROTECTED]> writes:
JvV> If this is the case, the code underlying the treading would utilize normal
functions to poll the concurrent event streams and programmers could
JvV> choose between the threads and functions depending on their levels of comfort.
JvV> Th
This thread seems to be winding down fttb**, Judging from the below, perl
multithreading [ I am guessing ] is simply syntatic sugar much the
same as Koch C++ is a wrapper for regular cc compiler.
This sounds nice,
> Threading Perl bytecode would be nice about 98% of the time, and
> sho
> "AT" == Adam Turoff <[EMAIL PROTECTED]> writes:
>> Wouldn't just the appearance of *foo = \&other_foo, be enough to tell
>> the compiler to treat all foo's (or perhaps if there were some dataflow
>> analysis some region of code) to use indirection?
AT> You're forgetting eval "*foo = \&othe
On Mon, Oct 23, 2000 at 11:03:12AM -0400, Chaim Frenkel wrote:
> > "AT" == Adam Turoff <[EMAIL PROTECTED]> writes:
> AT> It would also mean that if anything was overriden anywhere, no
> AT> module code could be read in as bytecode, since it may need to be
> AT> rethreaded to incorporate overr
At 08:45 AM 10/23/00 -0700, Larry Wall wrote:
>Adam Turoff writes:
>: If Perl bytecode were to become threaded, it would be rather troublesome.
>
>Wasn't actually suggesting it, though similar issues also arise for
>compiling down to efficient C, JVM, or C# IL. Optimizing for Least
>Surprise mean
Adam Turoff writes:
: If Perl bytecode were to become threaded, it would be rather troublesome.
Wasn't actually suggesting it, though similar issues also arise for
compiling down to efficient C, JVM, or C# IL. Optimizing for Least
Surprise means different things in different contexts, but I'd ha
> "AT" == Adam Turoff <[EMAIL PROTECTED]> writes:
AT> If Perl bytecode were to become threaded, it would be rather troublesome.
AT> It would probably require some attribute or early compile time
AT> declaration (in main::BEGIN) to tag specific subs/builtins to be
AT> overridden at runtime.
On Sat, Oct 21, 2000 at 08:59:21AM -0700, Larry Wall wrote:
> Joshua N Pritikin writes:
> : http://www.oreillynet.com/pub/a/python/2000/10/04/stackless-intro.html
>
> Perl 5 is already stackless in that sense, though we never implemented
> continuations. The main impetus for going stackless was
14 matches
Mail list logo
