[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]