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
60 matches
Mail list logo
