Front page | perl.perl5.porters |
Postings from January 2001
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 BurlisonThread Previous | Thread Next