On Tue, Oct 29, 2002 at 07:05:32PM +0000, Don Dade wrote: > Hello, > > Nothing happens to the execution context of the interrupted process. All > the regs are saved, and restored when the signal handler exits and the > original process gets rescheduled. That's what makes an asynch interrupt > different from a subroutine call. With subs, which are synchronous, you can > have a protocol which says who will manage the registers. With an > interrupt, which is asynchronous, it really must be the interrupt > function's proxy code. > And it is easy to find out what you can/can't do inside a handler. Look for > something about async signal safety in the man pages. Most linuxthreads > stuff is out of the question, but most kernel objects work as far as I > know. It is best to just set a flag and let processing be done elsewhere, > if possible. ... and that flag must be declared volatile, or GCC will load it to register and it will never notice it's change. As far as threads are concerned, the trouble is, that it does not care for any synchronization primitives. So it can be called in the middle of a critical section and that critical section won't finish until the handler returns (because it borrowed the context). > I'd look at "Advanced Programming in the Unix Enviroment", or "Practical > Unix Programming". > > HTH > > Don > > Anjaneyulu writes: > > >Hi, > >I would like to know when the signal handler will be executed on reception > >of a signal. During return from kernel mode, which may mean between any two instructions of the process if that return is from schedule. > >What happens to the process (which installed the signal handler) execution > >context???? > >Can anyone specify what all can be performed in a signal handler???? ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb@ucw.cz> -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
