Dan Sugalski wrote: > *) If, and *only* if, a variable is marked as shared, then its vtable > function pointer is replaced with a threadsafe version. (Or, rather, a > pointer to the 'use in case of threads' table--strictly speaking it doesn't > have to do any locking, but that would be pretty stupid) Multiple threads > can access the shared data (the thread that shared it and any threads it > spawns). We do no user-level locking, and if the low-level locking that the > vtable functions do to ensure we don't core dump is really expensive, well, > too darned bad) Hmm. Might be easier to say that shared variables are visible to all threads. I'm not sure that a parent/child relationship makes much sense between threads, and your proposal kinda implies that sort of relationship. > *) We *will* yank out any promises of what threads signals (or any async > event) fire off in. I really, *really* want to toss the promise of being > able to die from within a signal handler that catches a real signal, but I > don't know that Larry will go for that. (Expecting sane shutdown when you > essentially puke from within an interrupt handler's always struck me as a > semi-odd thing, though I understand the utility) to some extent If perl signal handlers are dispatched from the main loop at specified cancellation-safe points then calling die from a perl-level signal handler should be doable. The underlying C level handler will just have to be careful not to do anything that isn't async signal safe. If perl gets a proper event loop, aren't signals just another event? As for continuing the current pretence that you can write a 'real' signal handler in perl - well, even Larry can't make it so merely by wishing it so. > * We may put in a mechanism to direct an interrupt at a particular thread > (and probably will have to to preserve the 'die from a signal handler' > stuff, but that'll only work for perl-generated events and non-fatal > synchronous signals (of which there are very few)) What about automatically having a dedicated signal handling thread for any program that is user-level threaded? > I don't know what Larry will want from a language perspective, but this is > what he'll get from the core engine. I think this is the smallest safe set > of things we can do, and I'm reasonably sure that everything else anyone > might want can be layered on top, albeit slowly in some cases. A very sound strategy IMHO. Alan Burlison
