From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 928 invoked from network); 30 Oct 2000 16:18:43 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 30 Oct 2000 16:18:43 -0000 Received: (qmail 28271 invoked by alias); 30 Oct 2000 16:18:38 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13100 Received: (qmail 28262 invoked from network); 30 Oct 2000 16:18:35 -0000 From: "Bart Schaefer" Message-Id: <1001030161809.ZM17414@candle.brasslantern.com> Date: Mon, 30 Oct 2000 16:18:08 +0000 In-Reply-To: <200010300832.JAA18859@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: zsh-3.1.9-dev-6 crashes occassionally" (Oct 30, 9:32am) References: <200010300832.JAA18859@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: zsh-3.1.9-dev-6 crashes occassionally MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 30, 9:32am, Sven Wischnowsky wrote: } } Thomas uses a trap handler for the ALRM signal and with TMOUT=1 to } update his prompt. The trap handler uses several local parameters. } Since zsh invokes (shell-code) trap handler asynchronously from the } signal handler, this could easily mess up the parameter table if the } signal comes at a time when the completion code is playing with the } parameter table itself. An easy way to find out -- at the top of _main_complete, add local TMOUT=0 which will shut off the alarm timer during the completion functions. I just tested this by setting up a TMOUT=1 refresh of my xterm title bar, plus a completion function that does nothing but "sleep 5", and indeed the title bar stopped updating for 5 seconds when I pressed TAB. Zed does this same thing. One other item of note: For some strange reason, it's not possible to alter TRAPxxx functions with "zed -f". They come up in the editor, and if you create one from scratch it sticks, but no changes that you make to an already-existing TRAPxxx function are remembered. No matter how you exit zed, they always revert to their previous value. } We talked about this several times already. We either need to protect } parts of the code (blocking signals there) or we should make the } signal handlers do as little as possible, setting only some flags or } something like that and call the trap handler shell-code somewhere } else where it can be called savely. We `decided' to use the second } solution, I think (and the first one is expensive and we have to find } all the right places and...). I don't recall what the decision was, but setting a flag isn't enough in the case of TMOUT/TRAPALRM -- you also have to force the blocking read in getkey() to be interrupted and not restarted, or zsh will not get to "somewhere else" in a timely fashion. That means fooling with setjmp/longjmp, most likely, which is an entire other can of worms we might be better off not opening. } We could also use a mixture: a global flag that tells the signal code } that it's save to invoke the trap handler right away but normally it } would only make them be called later. That flag could be set when zsh } is waiting for an external command, reading somethin or whatever. That would probably be enough to take care of the blocking-read issue. However, our choice of "a safe place" to invoke the handler is still going to have be made with some care -- it has to be a place (or more than one) that is *guaranteed* to be reached quickly, and I just don't see how we can possibly enforce that when arbitrary module code may get involved. -- 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