Re: Safe signals, multiple signals?
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> Real Unix signals aren't going to get treated any differently from DS> any other event, though, so I'm not sure there's much to be gained DS> from treating them all that specially. They're just one more event DS> to be fed into a perl program. (The only really useful thing you DS> can do with signals that isn't really eventish is with alarm to DS> interrupt a blocked system call or something. But that doesn't DS> work with threads, and has other issues, so we'll be doing it a DS> different way) this goes back to rfc 350 where i propose the ability to have optional timeouts on most blocking i/o calls. if we have that, then there is no need to support the wacko alarm/die trick and no worries about how threads and signals interact. any thread can receive any signal it wants via the event system. simple. we could have a catch mechanism which is given its own timeout argument and when it times out, the operation (which can be anything) is stopped and the catch deals with the error code. no issue with the lack of multiple alarms either. having an event loop/handler in the core is so useful. :) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11 Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
RE: Safe signals, multiple signals?
At 10:56 AM 5/11/2001 -0700, Hong Zhang wrote: > > >There is no need to store pending signals. It will be impossible > > >to achieve in a multi-threaded perl runtime. > > > > No, it won't be that tough to get multiple pending signals for a thread. > > Not "real" Unix signals, perhaps, but what look like them, more or less. >If > > several alarms time out essentially simultaneously, or some I/Os finish at > > > the same time, a thread could have a stack of things to look at. > >Suppose we are talking about real unix signals. Otherwise, we can use event >loop for sending/processing event to do so. Real Unix signals aren't going to get treated any differently from any other event, though, so I'm not sure there's much to be gained from treating them all that specially. They're just one more event to be fed into a perl program. (The only really useful thing you can do with signals that isn't really eventish is with alarm to interrupt a blocked system call or something. But that doesn't work with threads, and has other issues, so we'll be doing it a different way) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Safe signals, multiple signals?
> >There is no need to store pending signals. It will be impossible > >to achieve in a multi-threaded perl runtime. > > No, it won't be that tough to get multiple pending signals for a thread. > Not "real" Unix signals, perhaps, but what look like them, more or less. If > several alarms time out essentially simultaneously, or some I/Os finish at > the same time, a thread could have a stack of things to look at. Suppose we are talking about real unix signals. Otherwise, we can use event loop for sending/processing event to do so. Since the kernel already has signal queue, we can take advantage of it by using sigwaitinfo(). We should limit normal signal handler for error handling only. That will make system design simpler. Hong
RE: Safe signals, multiple signals?
At 03:41 PM 5/10/2001 -0700, Hong Zhang wrote: > > similarly, proper safe signals will store all pending signals and > > deliver each one. > >There is no need to store pending signals. It will be impossible >to achieve in a multi-threaded perl runtime. No, it won't be that tough to get multiple pending signals for a thread. Not "real" Unix signals, perhaps, but what look like them, more or less. If several alarms time out essentially simultaneously, or some I/Os finish at the same time, a thread could have a stack of things to look at. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Safe signals, multiple signals?
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes: DLN> Uri Guttman wrote: >> >> multiple timers DLN> This means something like there is this array of sets of events, DLN> and a thread that shifts off the front one every second and DLN> feeds everythin in it into the event queue. Right? maybe. that is one method of doing delivery of events. my favorite style is with callbacks. let the event loop figure out the way to do the callback and who to call. your method requires you do always write your own event dispatcher which is redundant with that guy's :) so you queue up event requests each of which has args which select which of your objects/method or subs get called back. much less coding on your part. also threads can be handled easily with an optional event loop per thread or only one thread handling events and doing interthread communication. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11 Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
Re: Safe signals, multiple signals?
Uri Guttman wrote: > > multiple timers This means something like there is this array of sets of events, and a thread that shifts off the front one every second and feeds everythin in it into the event queue. Right? -- David Nicol 816.235.1187 [EMAIL PROTECTED] # die smiling;
Re: Safe signals, multiple signals?
> "HZ" == Hong Zhang <[EMAIL PROTECTED]> writes: HZ> There is no need to store pending signals. It will be impossible HZ> to achieve in a multi-threaded perl runtime. HZ> The only safe signals in multi-threaded system is using to use HZ> sigwaitinfo() for all process-wide signals. So there will be HZ> one dedicated thread waiting on sigwaitinfo() and it calls HZ> signal handler when it retrieve a signal. All other threads HZ> will block process-wide signals. We should only use regular HZ> signal handler for synchronous exception handling, such as HZ> SIGSEGV and SIGBUS. my concept already assumes a single thread handling process level signals. or at least only one thread is designated to handle any given signal. but you can still get multiple signals and they have to be recieved and stored before they can be delivered. this is true in a simple process or in multithreaded one. there will possibly be an option to compress multiple signals to a single delivered one. in general real signals will just bump a special global counter in the event loop and get delivered (which decrements the counter) at the next available opportunity which depends on the selected delivery method. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11 Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
RE: Safe signals, multiple signals?
> if we have a proper core event loop as dan and i want, multiple timers > will be part of that. and that will mean we can have timed out > operations without the mess of eval/die (or whatever 6 will have for > that). Event loop will be great for many applications. We probably need a better way to deal with timed out operations on general. > similarly, proper safe signals will store all pending signals and > deliver each one. There is no need to store pending signals. It will be impossible to achieve in a multi-threaded perl runtime. The only safe signals in multi-threaded system is using to use sigwaitinfo() for all process-wide signals. So there will be one dedicated thread waiting on sigwaitinfo() and it calls signal handler when it retrieve a signal. All other threads will block process-wide signals. We should only use regular signal handler for synchronous exception handling, such as SIGSEGV and SIGBUS. Hong
Re: Safe signals, multiple signals?
On Thu, 10 May 2001, Uri Guttman wrote: > > "DS" == Dave Storrs <[EMAIL PROTECTED]> writes: > > DS> There have been multiple mentions of the fact that we intend to have safe > DS> signals in Perl 6. I was wondering if it will also be possible to have > DS> more than one alarm() set at a time, or some other mechanism for having > DS> multiple pending signals. > > if we have a proper core event loop as dan and i want, multiple timers > will be part of that. and that will mean we can have timed out > operations without the mess of eval/die (or whatever 6 will have for > that). Cool. > > similarly, proper safe signals will store all pending signals and > deliver each one. Cooler. > a core event loop will support all of those features. delivery methods > can be chosen by the coder, either polling in the op code loop or > running a proper event loop with no polling (which will be faster). Completely frozen. (That's a compliment, in this context. :>) Dave
Re: Safe signals, multiple signals?
> "DS" == Dave Storrs <[EMAIL PROTECTED]> writes: DS> There have been multiple mentions of the fact that we intend to have safe DS> signals in Perl 6. I was wondering if it will also be possible to have DS> more than one alarm() set at a time, or some other mechanism for having DS> multiple pending signals. if we have a proper core event loop as dan and i want, multiple timers will be part of that. and that will mean we can have timed out operations without the mess of eval/die (or whatever 6 will have for that). similarly, proper safe signals will store all pending signals and deliver each one. a core event loop will support all of those features. delivery methods can be chosen by the coder, either polling in the op code loop or running a proper event loop with no polling (which will be faster). uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11 Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
Safe signals, multiple signals?
There have been multiple mentions of the fact that we intend to have safe signals in Perl 6. I was wondering if it will also be possible to have more than one alarm() set at a time, or some other mechanism for having multiple pending signals. Dave
