Re: General unqueue_signal problem

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

On Jun 13, 10:34am, Andrej Borsenkow wrote:
} Subject: General unqueue_signal problem
}
} > ld: 0711-317 ERROR: Undefined symbol: .handler
} 
} This comes from unqueue_signals() macro. This macro directly calls
} handler() from signals.c (at least, I presume it is this one). But
} as I understand, zftp.c sometimes install its own handler. Any other
} module may possible install own handler as well.

It would be a very bad idea in most cases for a module to install its
own signal handler.  Dispatch of the `trap' mechanism is done through
the handler() function, etc.  zftp goes to some lengths to do the right
thing in spite of this.

} I do not understand how signal queuing works - anybody cares to check
} it?

Most of the time signals that zsh doesn't want can simply be blocked and
the OS will queue them up and deliver them when they're unblocked.  In a
few cases it needs to let the signal be delivered but avoid dispatching
the traps mechanism or other code that would (for example) call malloc().

So zsh sets up its own internal queue (really, just pointers into a fixed
array of integers) where handler() records the numbers of the signals it
has caught.  When signals are dequeued, handler() is called a second time
to dispatch the signal as it would have if queuing had not been in force.

Since the signal wouldn't have gotten into the queue in the first place
unless handler() caught it, handler() is the right function to call to
finish dispatching it later, even if some other handler has been put in
place in the meantime.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net