Front page | perl.perl5.porters |
Postings from January 2001
On Sun, Jan 21, 2001 at 12:11:26PM +0000, Alan Burlison wrote: > setjmp/sigsetjmp are NOT thread safe and CANNOT be used in a threaded > program. Period. Perl5 uses setjmp even when built threaded, and is Bah. I wasn't assuming that we were going to use them But I'd forgotten the above. > I'm not sure that starting a thread per eval context is a sensible thing > to do. Threads are cheap, but not that cheap. it was more a brainstorming type idea. It wouldn't also work, because the eval context would either have to copy its invokers entire interpreter before starting, and then either "implode" if it dies, or substitute its interpreter in place of its parents if it doesn't die. We don't actually need the new thread, as the invoker of the eval doesn't run again until the eval finishes > 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) > Note that even if we used C++ it wouldn't help us in this case, because > although C++ does exceptions, it knows nothing about threads, mutexes or > CVs. I suspect the perl6 interpreter loop will look something like: 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. > 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 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 hey. we get a "sequence point" opcode. :-) > 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. and with a sequence point opcode it would be easy to parse the op tree and go: perl6 -wle '$a = 1; print ++$a / $a++' Multiple modifications of variable '$a' in a single expression will give unpredictable results. Nicholas ClarkThread Previous | Thread Next