Re: zsh-3.1.9-dev-6 crashes occassionally

[Peter Stephenson <pws@csr.com>]

Sven wrote:
> 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...).

Yes, and I was thinking about this recently, since I have a similar
requirement where it would fit the bill.

> 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.
> (This could be a good reason to finally write a function that is
> called everywhere zsh waits for something. And then we could allow
> modules to hook into it or something.)

I was hoping for the ability for modules to define their own traps,
unconnected with real signals, which would allow them to have an
asynchronous part for internal processing and a part that calls shell code
defined by the user.  You can get the effect with a hook, but special traps
make the interface more uniform.

I was also thinking about the possibility of having trashzle() called
automatically --- then you can get your function to produce output
apparently asynchronously, but actually when the keyboard read is
interrupted, and have the screen tidied up.  This would be very useful, but
I'm not clear how to get it to work: if the function doesn't know it's
going to produce output till after, you couldn't call trashzle() till the
end, which might have unexpected effects due to the tty settings.  On the
other hand, if you call trashzle() at the start and the function doesn't
produce output, you have surprised the user for no reason.

Needless to say I haven't got around to doing any work on this.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070