Re: Does perl really need to use sigsetjmp? (18%performancehit)
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes: AB> Uri Guttman wrote: >> my scheme allows the user to do that. they just create a regular thread >> and request all their signal events in that thread. but my design also >> allows different threads to handle different signals (and multiple >> threads to handle the same one). AB> Hmm. So how will you know the difference betwen a signal being AB> delivered once and handled twice and the same signal arriving twice? I AB> can see that multiple threads all handling the same signal could be very AB> confusing. event.pm does that right now. it uses counters which bump for each real signal that comes in and decrements for each one delivered. these counters would be shared and locked. it doesn't sound too hard to do. also like dan has been saying, there are certain restrictions we could place on the coder like not allowing more than one handler for the same signal even across threads. >> my main point there is that faking async i/o and sync signal delivery is >> much easier than faking threads. so we code all the internals to an >> event loop api and fake it underneath as needed on various >> platforms. much more on this soon. AB> As Jarkko would say: AB> Yes, yes yes. AB> :-) so stop bothering me so i can write up the damned thing. :) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: Does perl really need to use sigsetjmp? (18%performancehit)
Uri Guttman wrote: > my scheme allows the user to do that. they just create a regular thread > and request all their signal events in that thread. but my design also > allows different threads to handle different signals (and multiple > threads to handle the same one). Hmm. So how will you know the difference betwen a signal being delivered once and handled twice and the same signal arriving twice? I can see that multiple threads all handling the same signal could be very confusing. > my main point there is that faking async i/o and sync signal delivery is > much easier than faking threads. so we code all the internals to an > event loop api and fake it underneath as needed on various > platforms. much more on this soon. As Jarkko would say: Yes, yes yes. :-) Alan Burlison
Re: Does perl really need to use sigsetjmp? (18% performancehit)
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> The issue of 'which thread' comes in with signals. We can tell DS> with real async events, since they'll have thread ownership tags DS> on them if we care, but we can't do that with signals, and then we DS> have the issue of "which thread" to deal with? DS> All the synchronous signals I know of are fatal, and all the async DS> ones won't tell us which thread. And, of course, there are the DS> ones that may or may not be async (like SIGPIPE) for more fun. So DS> while we *could* die from a signal handler, none of the ones we DS> can catch can be associated with a thread. This isn't the case for DS> non-signal signals like the die and warn handlers, but they're not DS> strictly speaking signal handlers. my view is that each thread gets its own interpreter and as such gets its own event loop (working with the assumption that the op code loop is tight (or the same) as the event loop). then the coder has the obligition to request a signal event. when the real signal comes in, perl guts sets/increments a global (and thread safe) counter. only those interpreter threads/event loops looking for that signal will have it delivered to them. so there is no issue about which thread gets a signal. >> What about automatically having a dedicated signal handling thread for >> any program that is user-level threaded? DS> I'm torn between doing that and not, since firing up a second DS> OS-level thread can add some overhead that we might not need with DS> the "set a flag and check on op boundary" setup. I know that VMS DS> won't kick over to the slower fully threadsafe version of its DS> runtime libraries until you actually start a second thread, and I DS> thought Solaris did something similar. my scheme allows the user to do that. they just create a regular thread and request all their signal events in that thread. but my design also allows different threads to handle different signals (and multiple threads to handle the same one). in fact, i was working on a design a couple of years ago that was going to share a single event loop among multiple c threads. i think that isn't going to work here so the interpreter/event loop per thread concept is best. by allowing any thread to handle any signal, we give the coder maximal flexibility without tying perl guts to any thread requirements. this would work the same on a non-thread OS as one which has threads. i am working on a proposal to handle socket and async file i/o in the guts in a consistant way across any platform (supporting any combination of those services) and it works well under this model. i should have it written up in a couple of days. my main point there is that faking async i/o and sync signal delivery is much easier than faking threads. so we code all the internals to an event loop api and fake it underneath as needed on various platforms. much more on this soon. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: Does perl really need to use sigsetjmp? (18%performancehit)
At 11:04 PM 1/21/01 +, Alan Burlison wrote:
>Dan Sugalski wrote:
>
> > 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.
>
>It's linking to libthread that makes it use the thread-safe versions of
>stuff:
Ah, different than what I expected. ISTR some systems (possibly just the
Digital ones) do some odd things with the libraries, basically having the
whole runtime library being vectored, and firing off a thread changed the
vectors from the non-threaded to the threaded version. Makes writing
thread-agnostic code easier, since you can do locking if you need to but
don't necessarily have to slow down the entire RTL system. (No need for
malloc to lock, for example, in single-threaded code, since there's nothing
that could require them be taken as you're, well, single threaded)
I could be talking out my hat, though, as it's been a while and my memory's
an interesting thing. ("reliable" is not an appropriate adjective for it... :)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Does perl really need to use sigsetjmp? (18%performancehit)
Dan Sugalski wrote:
> 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.
It's linking to libthread that makes it use the thread-safe versions of
stuff:
$ cat z.c
int main () { abort(); }
$ cc -o z z.c; ./z; pstack core
Abort(coredump)
core 'core' of 193353: ./z
ff3194d0 _kill(ff336000, 0, ff3385a8, 5, 229bc, ff29b784) + 8
0001061c main (1, ffbef8ac, ffbef8b4, 20800, 0, 0) + 4
000105f0 _start (0, 0, 0, 0, 0, 0) + b8
$ cc -o z z.c -mt; ./z; pstack core
Abort(coredump)
core 'core' of 193574: ./z
- lwp# 1 / thread# 1
ff369494 __sigprocmask (ff36bdb8, 0, 0, 20860, ff37e000, 0) + 8
ff35da38 _sigon (20860, ff3859a0, 6, ffbef6f4, 20860, 1) + d0
ff360abc _thrp_kill (0, 1, 6, ff37e000, 1, ff33a480) + f8
ff2ca840 raise(6, 0, 0, , ff33a3ec, ) + 40
ff2b4c04 abort(ff336000, 0, ff3385a8, 5, 100d4, 0) + 100
00010624 main (1, ffbef8ac, ffbef8b4, 20800, 0, 0) + 4
000105f8 _start (0, 0, 0, 0, 0, 0) + b8
- lwp# 2 / thread# 2
ff318690 _signotifywait (ff37e000, 145, 0, 0, 0, 0) + 8
ff361930 thr_yield (0, 0, 0, 0, 0, 0) + 8c
- lwp# 3
ff316234 _door_return (3, ff37f6d8, ff37f6f0, 3, ff37e000, 1) + 10
ff35a1cc _lwp_start (ff245d70, 0, 6000, ffbef19c, 0, 0) + 18
ff361930 thr_yield (0, 0, 0, 0, 0, 0) + 8c
-- thread# 3
ff35d6e4 _reap_wait (ff382a50, 20bf8, 0, ff37e000, 0, 0) + 38
ff35d43c _reaper (ff37ee80, ff3847b0, ff382a50, ff37ee58, 1, fe40)
+ 38
ff36b4a0 _thread_start (0, 0, 0, 0, 0, 0) + 40
Alan Burlison
Re: Does perl really need to use sigsetjmp? (18% performancehit)
At 10:00 PM 1/21/01 +, 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
Re: Does perl really need to use sigsetjmp? (18% performancehit)
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
