Dan Sugalski <[EMAIL PROTECTED]> writes:
>>Nick has yet to touch sv_gets() - partly 'cos it was too scary to mess
>>with - so you can if you like ;-)
>
>(As I dig through old mail...)
>
>What I was thinking of was making the scalar behind $/ magic,
It already is - you mean more magical? i.e. stu
At 03:11 PM 1/8/01 +, Nick Ing-Simmons wrote:
>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 go
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 04:01 PM 1/6/01 +, Simon Cozens wrote:
>>On Sat, Jan 06, 2001 at 10:59:04AM -0500, Dan Sugalski wrote:
>> > >Which is exactly what Chip did in his safe-signals patch. 33% slowdown.
>> > I think you misremember that number. IIRC it was somewhere betw
At 07:19 PM 1/10/01 +, [EMAIL PROTECTED] wrote:
>Uri Guttman <[EMAIL PROTECTED]> writes:
> >> "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
> >
Uri Guttman <[EMAIL PROTECTED]> writes:
>> "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(
> "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
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(
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
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
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
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
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
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> 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, eithe
On Sat, Jan 06, 2001 at 01:06:51PM -0500, Dan Sugalski wrote:
> At 04:01 PM 1/6/01 +, Simon Cozens wrote:
> >Gosh, really? I thought it was so significant that it didn't go in core.
> >If it was that small, why *didn't* it go in core?
>
> Because a guaranteed 3-5% slowdown in the interpreter
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> On Sat, Jan 06, 2001 at 10:59:04AM -0500, Dan Sugalski wrote:
>> >Which is exactly what Chip did in his safe-signals patch. 33% slowdown.
>> I think you misremember that number. IIRC it was somewhere between 3%-5%.
SC> Gosh, rea
> 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.
> Piggybacking on the end of statement cleanup opcode might be a b
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 get in the
>i/o and event guts. but then, i hav
At 04:01 PM 1/6/01 +, Simon Cozens wrote:
>On Sat, Jan 06, 2001 at 10:59:04AM -0500, Dan Sugalski wrote:
> > >Which is exactly what Chip did in his safe-signals patch. 33% slowdown.
> > I think you misremember that number. IIRC it was somewhere between 3%-5%.
>
>Gosh, really? I thought it was
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 11:49 AM 1/6/01 +, Simon Cozens wrote:
>> 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
>> > syste
On Sat, Jan 06, 2001 at 10:59:04AM -0500, Dan Sugalski wrote:
> >Which is exactly what Chip did in his safe-signals patch. 33% slowdown.
> I think you misremember that number. IIRC it was somewhere between 3%-5%.
Gosh, really? I thought it was so significant that it didn't go in core.
If it was
At 11:49 AM 1/6/01 +, Simon Cozens wrote:
>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
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 on each pass thru the loop.
Which is exactly w
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> This is the Perl interpreter:
SC> while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
SC> PERL_ASYNC_CHECK();
SC> }
SC> The only problem is that right now, PERL_ASYNC_CHECK doesn't actually
SC> do anything.
On Fri, Jan 05, 2001 at 07:39:36PM -0500, Uri Guttman wrote:
> the former means the ENTIRE guts of perl would be run on the event
> loop. this is a cool idea IMO. the perl interpreter IS an event loop.
>
> so tell me, is that nuts or what? :)
No, it's exactly what Perl 5 does.
This is the Perl
> "n" == <[EMAIL PROTECTED]> writes:
n> I have some sympathy with Uri's position here. Signals and event
n> loops are close cousins. What I am less clear about is whether we
n> want to go down the Tcl route, or do something even more radical
n> like making op despatch and the event
25 matches
Mail list logo
