From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.auc.dk
Subject: Re: zsh-3.1.9-dev-6 crashes occassionally
Date: Mon, 30 Oct 2000 16:18:08 +0000 [thread overview]
Message-ID: <1001030161809.ZM17414@candle.brasslantern.com> (raw)
In-Reply-To: <200010300832.JAA18859@beta.informatik.hu-berlin.de>
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
next prev parent reply other threads:[~2000-10-30 16:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-30 8:32 Sven Wischnowsky
2000-10-30 9:56 ` Peter Stephenson
2000-10-30 10:10 ` Thomas Köhler
2000-10-30 16:18 ` Bart Schaefer [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-11-08 10:54 Sven Wischnowsky
2000-11-08 9:41 Sven Wischnowsky
2000-11-08 10:33 ` Thomas Köhler
2000-11-01 9:41 Sven Wischnowsky
2000-11-03 15:42 ` Bart Schaefer
2000-11-05 17:55 ` Thomas Köhler
2000-10-31 15:42 Sven Wischnowsky
2000-10-31 13:19 Sven Wischnowsky
2000-10-31 13:51 ` Peter Stephenson
2000-10-31 14:01 ` Sven Wischnowsky
2000-10-31 15:25 ` Bart Schaefer
2000-10-31 15:43 ` Andrej Borsenkow
2000-10-30 10:25 Sven Wischnowsky
2000-10-24 7:53 Sven Wischnowsky
2000-10-23 13:04 Sven Wischnowsky
2000-10-23 15:12 ` Thomas Köhler
2000-10-21 12:34 Thomas Köhler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1001030161809.ZM17414@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).