At 10:00 PM 1/21/01 +0000, Alan Burlison wrote:
>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.
Well, since we're tossing refcounting for GC, I was thinking of
implementing a sort of memory list for things referred to outside the
current interpreter. (Generally extension code and other thread) I was
figuring that we'd inherit from that, so putting variables on the shared
list would mean they'd be looked at only when we cloned off an interpreter.
That's the lazy way, though, so propagating shared variables out to the
world's not a huge deal. A SMOP, and a cost we won't pay all that often.
> > *) 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?
Yup, though rather simplistic ones.
The issue of 'which thread' comes in with signals. We can tell with real
async events, since they'll have thread ownership tags on them if we care,
but we can't do that with signals, and then we have the issue of "which
thread" to deal with?
All the synchronous signals I know of are fatal, and all the async ones
won't tell us which thread. And, of course, there are the ones that may or
may not be async (like SIGPIPE) for more fun. So while we *could* die from
a signal handler, none of the ones we can catch can be associated with a
thread. This isn't the case for non-signal signals like the die and warn
handlers, but they're not strictly speaking signal handlers.
>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'm torn between doing that and not, since firing up a second OS-level
thread can add some overhead that we might not need with the "set a flag
and check on op boundary" setup. I know that VMS won't kick over to the
slower fully threadsafe version of its runtime libraries until you actually
start a second thread, and I thought Solaris did something similar.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
