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
Filipe Brandenburger <[EMAIL PROTECTED]> writes:
>
>But, back to the efficiency issue, I _THINK_ the scenario I described is not
>inefficient. What it does differently from a monolithic system: it uses
>callbacks instead of fixed function calls, and it doesn't inline the
>functions. First, Cal
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(
> "RC" == Rocco Caputo <[EMAIL PROTECTED]> writes:
RC> Re: Writing the subsystems together.
RC> I think you misunderstand the other message's intent. The main loop,
RC> the interpreter, and I/O, are three separate subsystems. I think
RC> everyone agrees with you that they should b
great
> data manipulation library only to rewrite it in every subsystem?
>
> -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
>
>
>
I'm sorry I didn't express myself OK..., but we're in violent agreement.
Please read my previous post to the perl6-internals mail-list, entitled
``Modular subsystem design (was Re: Speaking of signals...)''
Your ``pluggable'' idea is just what I was looking for. To me, that's what
perl6 needs to be.
Branden
On Mon, 8 Jan 2001 23:12:15 -0200, Filipe Brandenburger wrote:
>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 th
Nicholas Clark wrote:
>Branden wrote:
>> That's actually something I'd like to say about this ``subsystem''-based
>> design of perl6. For it to be successful, it's imperative that all the
>> modules
>> don't know about each other, so that it's possible to replace a subsystem
>> c
On Mon, Jan 08, 2001 at 11:12:15PM -0200, Filipe Brandenburger wrote:
> 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 lon
On Mon, Jan 08, 2001 at 11:12:15PM -0200, Filipe Brandenburger wrote:
> In the other way around, what matters to the design of the file i/o
> subsystem is exactly the same thing: whether it will or won't be using
> blocking syscalls. I believe after the decision of whether we will or not
> allow b
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
> "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
On Fri, 5 Jan 2001 23:46:33 -0500, Uri Guttman wrote:
>> "RC" == Rocco Caputo <[EMAIL PROTECTED]> writes:
>
> RC> With a tightly integrated event loop, blocking perl level I/O can be
> RC> implemented in terms of internal asynchronous I/O. An interpreter can
> RC> then block while perl is
> "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
On Fri, 5 Jan 2001 16:47:25 -0500, Uri Guttman wrote:
>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> I'm less worried about long running ops (whose fix is just a SMOP,
> DS> after all... :) than I am blocked ops. We can be as clever as we
> DS> want with event dispatch and asy
> "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.
> "RC" == Rocco Caputo <[EMAIL PROTECTED]> writes:
RC> With a tightly integrated event loop, blocking perl level I/O can be
RC> implemented in terms of internal asynchronous I/O. An interpreter can
RC> then block while perl is free to do other things, like say run other
RC> interpret
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
> "n" == <[EMAIL PROTECTED]> writes:
>> I'm less worried about long running ops (whose fix is just a SMOP, after
>> all... :) than I am blocked ops. We can be as clever as we want with event
>> dispatch and async handling but it won't do us a darned bit of good if the
>> interpre
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> do you mean event_flag is set to the actual op to handle the event? cute
>> use of a value based flag.
DS> The problem there is that it gets in the way if multiple events
DS> are pending, unless there's exactly one possible routin
Dan Sugalski <[EMAIL PROTECTED]> writes:
>>do you mean event_flag is set to the actual op to handle the event? cute
>>use of a value based flag.
>
>The problem there is that it gets in the way if multiple events are
>pending, unless there's exactly one possible routine we can call, in which
>cas
> "n" == nick <[EMAIL PROTECTED]> writes:
n> It is my personal style to use non-NULL value as "flag" - it dates
n> back to "my" RTOS on TI's 16-bit micros where memory was precious -
n> having a flag and a value was wasteful.
in my rt-11 assembly and heavy c days i did it too. i pro
At 03:57 PM 1/5/01 -0500, Uri Guttman wrote:
> > "n" == nick <[EMAIL PROTECTED]> writes:
> n>op_ptr = event_flag; // it _is_ the ops we want to do
> n>event_flag = NULL;
>
>do you mean event_flag is set to the actual op to handle the event? cute
>use of a value based flag.
The pr
Uri Guttman <[EMAIL PROTECTED]> writes:
>
> n>push(op_ptr);
>
>fake recursion. :) this is simpler, saving the old op to a stack. you
>need to also deal with popping that back when the handler is done.
Again using hardware as a model I would like an event "context switch"
to look like a "cal
> "n" == nick <[EMAIL PROTECTED]> writes:
>> that is so we don't dispatch events between every op code.
n> Why not? - hardware does.
n> Also once event is posted we keep going into the decrement loop
n> for all the ops until we decide to do it.
n> I don't think despatching ever
Uri Guttman <[EMAIL PROTECTED]> writes:
> n> Explain your counter idea some more (I will _read_ rather than skim
> n> the RFCs one of these days...)
>
> n> It seems to me that decrementing counter is extra inner-loop cost,
> n> and you still have the conditional branch delay when you test
> n
> "n" == nick <[EMAIL PROTECTED]> writes:
>> a single test flag which is set by a
>> variety of events is all that is needed. but we also should have an op
>> loop with no test as the code could use an event loop to handle all
>> events. then dispatching is not done inline. would it
At 01:19 PM 1/5/01 -0500, Uri Guttman wrote:
> > "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
> >> and where is the event test call made?
>
> NI> It isn't. PL_next_op is set by C signal handler.
>
>and that has to be memory and data structure safe.
>
> NI> In practice I suspect
Uri Guttman <[EMAIL PROTECTED]> writes:
>
>we are in violent agreement.
I think so too ;-)
>a single test flag which is set by a
>variety of events is all that is needed. but we also should have an op
>loop with no test as the code could use an event loop to handle all
>events. then dispatching
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>> and where is the event test call made?
NI> It isn't. PL_next_op is set by C signal handler.
and that has to be memory and data structure safe.
NI> In practice I suspect we need the test :
NI> while (PL_op = (PL_sig_op) ? P
Uri Guttman <[EMAIL PROTECTED]> writes:
>
>but the question remains, what code triggers a signal handler? would you
>put a test in the very tight loop of the the op dispatcher?
Not a test. The C level signal handler just fossicks with the variables
that very tight loop is using.
>
> n> But i
> "n" == nick <[EMAIL PROTECTED]> writes:
n> Uri Guttman <[EMAIL PROTECTED]> writes:
>>
>> that is my concept of inline delivery. in the op dispatch loop, either a
>> counter is used or a special op (which was automatically code generated
>> is called and then all pending events (
Uri Guttman <[EMAIL PROTECTED]> writes:
>> "IS" == <[EMAIL PROTECTED]> writes:
>
> IS> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> IS> I have some sympathy with Uri's position here. Signals and event
> IS> loops are close cousins. What I am less clear about is whether we
> IS> want to g
> "IS" == <[EMAIL PROTECTED]> writes:
IS> Dan Sugalski <[EMAIL PROTECTED]> writes:
IS> I have some sympathy with Uri's position here. Signals and event
IS> loops are close cousins. What I am less clear about is whether we
IS> want to go down the Tcl route, or do something even more
Sam Tregar <[EMAIL PROTECTED]> writes:
>On Wed, 3 Jan 2001, Dan Sugalski wrote:
>
>> I think one of the things we might want to do is figure out what people use
>> signals for and see if we can abstract out some of that functionality
>> without actually exposing signals. (From an internals standpo
Dan Sugalski <[EMAIL PROTECTED]> writes:
>Using alarm and $SIG{ALRM} to abort blocked or long-running things is one
>of the biggies (personally I think I'd prefer some sort of eval block with
>a timeout attached), since it doesn't work threaded, doesn't work well
>outside of Unix/VMS (read: Win
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Right. I'm not talking about getting rid of signals--I want to make them
DS> work properly in perl 6, %SIG and all. What I'm thinking about is those
DS> things that signals are used for but aren't particularly optimal.
DS> Usin
At 10:15 AM 1/4/01 -0500, Sam Tregar wrote:
>On Wed, 3 Jan 2001, Dan Sugalski wrote:
>
> > I think one of the things we might want to do is figure out what people use
> > signals for and see if we can abstract out some of that functionality
> > without actually exposing signals. (From an internals
On Wed, 3 Jan 2001, Dan Sugalski wrote:
> I think one of the things we might want to do is figure out what people use
> signals for and see if we can abstract out some of that functionality
> without actually exposing signals. (From an internals standpoint, at least)
Well, one thing people use s
Here is the complete list of SunOS signals (as reported by "kill -l"),
with possible uses for each. Some I'm discounting as "not useful"
(for Perl programs), but it ain't necessarily so...
=over 4
=item HUP
Prodding daemons, dealing with loss of interactivity
=item INT, QUIT, TERM (#15, pres
> "BT" == Bennett Todd <[EMAIL PROTECTED]> writes:
BT> How about, goosing long-lived daemons to ask 'em to re-read their
BT> config files? The only signal code I ever wrote for perl was for
BT> that --- and never did manage to work my way around to testing the
BT> resulting code enoug
2001-01-03-21:43:39 Dan Sugalski:
> I think one of the things we might want to do is figure out what people use
> signals for [...] The big one I can think of is interrupting
> timers. [...] (Excepting I/O signalish things, which will get
> handled elsewhere)
How about, goosing long-lived daemon
I think one of the things we might want to do is figure out what people use
signals for and see if we can abstract out some of that functionality
without actually exposing signals. (From an internals standpoint, at least)
The big one I can think of is interrupting timers. Right now people use
61 matches
Mail list logo
