develooper Front page | perl.perl5.porters | Postings from January 2001

Re: Does perl really need to use sigsetjmp? (18% performance hit)

Thread Previous | Thread Next
From:
Alan Burlison
Date:
January 21, 2001 06:06
Subject:
Re: Does perl really need to use sigsetjmp? (18% performance hit)
Message ID:
3A6AECEF.7F89717D@uk.sun.com
Nicholas Clark wrote:

> > Basically there is no free lunch here - if we want to use threads and do
> > exception handling in perl6 we will have to roll our own.  If perl6 has
> > something akin to the perl5 stack, eval/die will have to be implemented
> > so that that it rolls back up the stack on die, rather than the current
> > longjmp hack.
> 
> This makes sense. I'm reasoning (well, guessing) that eval really needs
> interpreter data structures that let us make a proposed set of changes,
> and then roll back or commit them when the eval exits
> (can any relational database nest transactions? if not, then perl has do to
> something more than they do)

I'm leery of this idea of putting transactions into perl.  There was a
very long-winded thread during the p6 RFC phase that suggested this very
thing.  If you want to know the gory details, I'm sure it is archived
somewhere.  The upshot is that database transactions are not a good
model for perl.  For example, what does 'transaction' mean in the
context of perl?  Exactly *what* do you and (more importantly) don't you
roll back?  How do you 'roll back' an IPC or network IO?  How do you
'roll back' a read/write from a shared filehandle?  Adding transactions
to perl would fundamentally alter the semantics of the language, would
confuse the hell out of anyone trying to use it, and probably would be
nearly impossible to implement correctly.  No!  Don't go there!

> I'm assuming that if you wrap up them up in a suitable object each, with
> a destructor to release them, it can be taught to do them.

Not that simple.  Firstly you need to distinguish between mutex/CVs that
are internal to the interpreter (e.g. the malloc lock) and those that
are application level.  At application level you might want to release
the mutex, sometimes not; destroy it sometimes, and other times not. 
CVs, reader/write locks etc etc are more complex still.  Personally I'm
sure that using script-level threads and die() in a perl program is ever
going to work satisfactorily without explicit control by the program. 
Here is a direct quote from the 'Programming with POSIX Threads' book,
talking about thread cancellation, which is very similar to a die():

"It might seem that the thread system could automatically release the
mutex; but most of the time that's no help.  Threads lock mutexes
because they're modifying shared data.  No other thread can know what
data has been modified or what the thread was trying to change, which
makes it difficult to fix the data.  Now the program is broken.  ... The
only way to recover from terminating a thread with a locked mutex is for
the application to analyze all shared data and repair it to achieve a
consistent and correct state.  That is not impossible, and it is worth a
substantial effort when the application must be fail-safe.  However,
that is generally not practical for anything other than an embedded
system where the application designers control every bit of shared state
in the process.  You would have to rebuild not only your own program or
library state, but also the state affected by any library functions that
might be called by the thread (for example the ANSI C library)."

If you have access to a Solaris box, take a look at the
cancellation(3THR) manpage, or go to http://docs.sun.com.

Whenever the subject of threads, mutexes etc in perl come up there
always seems to be suggestions that V1 of whatever is being proposed
should be some unutterably complex monster with all sorts of handwavery
magic going on behind the scenes to 'make life easier for the
programmer'.  Whilst I applaud the sentiment,  the minor details of
semantics (let alone implementation) seem to be conveniently put to one
side.  Please, let's get something a) well architected b) simple and c)
robust working first before we start trying to do a PhD project.

Alan Burlison

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About