[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]
Re: [ID 19991229.003] perl 5.005_03 core dumps -- singal
Ilya Zakharevich writes:
: Simon Cozens writes:
: > >And if you do not like the interface, write a module which
: > >deparses
: > >
: > > sub { ++$count; return }
: > >
: > >to [ inc => \$count ]. Make assignment to $SIG autoload this module.
: > >If deparse fails, enable the delayed samantic.
: >
: > I hate to suggest this, but wouldn't
: > $SIG{FOO} = sub { ++$count; return }
: > be easier for all concerned?
:
: Hmm, is not this what I proposed?
Yes, and it's still relatively useless in the overall scheme of things.
The purpose of a signal is to force the scheduler to run some meaningful
code. Just because C prevents this doesn't mean we can't fake it in Perl.
: > This seems wasteful:
: > If you disallow running arbitary code, you're restricting people.
:
: You cannot run arbitrary code in an immediate sighandler. If you
: delay execution, you are restricting people.
We can make that restriction relatively insignificant.
: > If you allow, say, a `[code => sub { ... }]', everyone will use that
: > instead of the other `instructions', out of laziness.
:
: Their lazyness is nothing of our concern.
You mean, their laziness is nothing of *your* concern. It is certainly
my concern. That's just one of the things a language designer has to
take into account.
Larry
- Follow-Ups from:
-
Ilya Zakharevich <ilya@math.ohio-state.edu>
- References to:
-
Ilya Zakharevich <ilya@math.ohio-state.edu>
[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]