From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2393 invoked from network); 13 Jun 2001 11:07:14 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Jun 2001 11:07:14 -0000 Received: (qmail 16029 invoked by alias); 13 Jun 2001 11:06:24 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14898 Received: (qmail 16005 invoked from network); 13 Jun 2001 11:06:23 -0000 X-Authentication-Warning: candle.brasslantern.com: schaefer set sender to lantern@shell10.ba.best.com using -f From: "Bart Schaefer" Message-Id: <1010613105728.ZM26315@candle.brasslantern.com> Date: Wed, 13 Jun 2001 10:57:28 +0000 In-Reply-To: <000401c0f3d2$dd2dc560$21c9ca95@mow.siemens.ru> Comments: In reply to "Andrej Borsenkow" "General unqueue_signal problem" (Jun 13, 10:34am) References: <000401c0f3d2$dd2dc560$21c9ca95@mow.siemens.ru> X-Mailer: Z-Mail (5.0.0 30July97) To: "Andrej Borsenkow" , "ZSH Workers Mailing List" Subject: Re: General unqueue_signal problem MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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