Front page | perl.perl5.porters |
Postings from January 2001
At 10:09 PM 1/21/01 +0000, Alan Burlison wrote:
>Dan Sugalski wrote:
>
> > >In other words the C level signal handler will have to do no more than
> > >setting a flag, as will the implementation of die(). By cancellation
> > >point I mean somewhere that is defined as 'safe', i.e. not holding any
> > >mutexes or waiting on any CVs etc.
> >
> > I'm not sure the core should really care about that. It's arguably not the
> > interpreter's problem. (Though it's not a strong argument)
>
>Ah - I mean not holding locks etc inside the interpreter core, not in
>the application. Fixing the application is the application programmers
>problem ;-) Seriously, I'm not sure that we could fix the genric
>application-level problem even if we wanted to. However, we *could*
>probably get it right for the interpreter innards.
Oh, right. Hard and fast rule is that no internal locks will be held across
an opcode boundary, period. Yeah, we may need to do odd things for sub
calls and evals so we don't recursively fire off runops loops, but I'm OK
with that, and I don't see where it should cost us anything anywhere but in
the actual sub call and eval opcode functions.
Beyond that, I'm tempted to have the thread docs be one sentence:
Go for it, and good luck!
:)
> > > I suspect a reasonable thing might
> > >be to have a special 'Now it is safe' opcode that is put out by the
> > >compiler at the appropriate places. It would be nice if this
> > >corresponded to a syntactic boundary such as an entire statement, so
> > >that for example
> > >
> > > my $a = $b * $c / $d;
> > >
> > >was guaranteed to either to be fully evaluated or not at all.
> >
> > The question, then, is what do we do with function calls in there (say, $a
> > = $b + foo()), and what about really long running statements like:
> >
> > $a = $b + 12 while 1;
>
>Hmm. Good point. Actually, I'd just settle for any point that didn't
>result in the interpreter being screwed up afterwards.
Works for me. The big reason to go sub-statement is for better
responsiveness, but then it firing off threads is simple enough we can tell
folks that's what they should do if they want their events handled with
reasonably small latency.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk
Thread Previous
|
Thread Next