On Sat, 6 Jan 2001 00:45:11 +, Simon Cozens wrote:
>No, it's exactly what Perl 5 does.
>
>This is the Perl interpreter:
>while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
>PERL_ASYNC_CHECK();
>}
>
>The only problem is that right now, PERL_ASYNC_CHECK doesn't actually
>do a
On Mon, Jan 08, 2001 at 11:39:11AM +0100, Bart Lateur wrote:
> >This is the Perl interpreter:
> >while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
> >PERL_ASYNC_CHECK();
> >}
> >
> >The only problem is that right now, PERL_ASYNC_CHECK doesn't actually
> >do anything. :)
>
> I
> But yes, I see no way to put perl solely under the GPL. That's just about
> the worst thing we could do, aside from making perl non-"free."
This is now *way way* off topic for perl6-internals. A relevant issue for
perl6-internals had been whether we could or should rely on an LPGL
library (gm
Nicholas Clark <[EMAIL PROTECTED]> writes:
>> sure if there are any non-two's complement machines out there anymore,
>
>However, as perl5 has a few 2s complement assumptions already polluting the
>source, unless we can find a 1s complement (or other) machine to test on, it
>seems sensible (to me
Simon Cozens <[EMAIL PROTECTED]> writes:
>On Fri, Jan 05, 2001 at 11:42:32PM -0500, Uri Guttman wrote:
>> SC> 5x slowdown.
>>
>> not if you just check a flag in the main loop. you only check the event
>> system if you have pending events or signals, etc. the key is not
>> checking all events o
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 01:02 PM 1/6/01 -0500, Uri Guttman wrote:
>>that is what i would expect form a simple flag test and every N tests
>>doing a full event poll. and even up to 5-10% slowdown i would think is
>>a good tradeoff for the flexibilty and ease of design win we ge
Bart Lateur <[EMAIL PROTECTED]> writes:
>
>Apropos safe signals, isn't it possible to let perl6 handle avoiding
>zombie processes internally? What use does having to do wait() yourself,
>have anyway?
Valid point - perl could have a CHLD handler in C and stash away returned
status to pass to wait(
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> Bart Lateur <[EMAIL PROTECTED]> writes:
>>
>> Apropos safe signals, isn't it possible to let perl6 handle avoiding
>> zombie processes internally? What use does having to do wait() yourself,
>> have anyway?
NI> Valid poi
This was the subject of a list and an RFC. I'd hope not to see what we
worked hard to come up with not go to waste, guys and gals. We came up
with a "least of all evils" solution, I think, and I feel very strongly
that not protecting Perl from outright theft, especially using very iffy
licenses al
Good morning.
I've been thinking about defining atomic code units for a while, and I
even posted something about it to p5p a few years back. The idea has
matured since then, and I'd like to quickly outline it here:
I've been defining code atoms using three rules:
1. Atoms begin at branch desti
On Mon, Jan 08, 2001 at 01:24:06PM +, David Grove wrote:
> This was the subject of a list and an RFC. I'd hope not to see what we
> worked hard to come up with not go to waste, guys and gals. We came up
> with a "least of all evils" solution, I think, and I feel very strongly
Where can this s
Rocco Caputo wrote:
> ...
> [ *** code *** ]
>
>This could very well be an event driven program, with all the tedious
>mucking about with callbacks done under the hood. Regardless, it could
>run the same as long as either threads OR async I/O are available.
Is this portable enough for Perl? Ar
At 12:09 PM 1/6/01 -0600, Jarkko Hietaniemi wrote:
> > Some of this ground does need to be revisited, since perl 6 isn't going to
> > be perl 5, and the tradeoffs are going to be different. (I'm still not
> sure
> > that checking for pending events every opcode is the way to go, either.
> > Piggy
13 matches
Mail list logo
