Zsh Mailing List Archive
Messages sorted by:
Re: PATCH: Re: Allowing traps
- X-seq: zsh-workers 13182
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx (Zsh hackers list)
- Subject: Re: PATCH: Re: Allowing traps
- Date: Wed, 22 Nov 2000 17:33:45 +0000
- In-reply-to: <1001120173911.ZM10192@xxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <0G4C000ND1N3ZY@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1001120173911.ZM10192@xxxxxxxxxxxxxxxxxxxxxxx>
On Nov 20, 5:39pm, Bart Schaefer wrote:
} Subject: PATCH: Re: Allowing traps
} On Nov 20, 4:54pm, Peter Stephenson wrote:
} } That doesn't fix the problem that the shell will try and run traps already
} } in the queue from within shell code called from the trap handler
} Yes, that is a problem.
I was about to commit the patch when I began to get really worried about
the whole trap-queuing idea.
My biggest concern is that a trap that calls `exit' or `return' will be
queued, thereby allowing code that should not have run to execute before
the trap queue is processed. (My patch would actually make this more
likely, which is what stopped me committing it.)
Traps are being queued during most of the time the shell is running, and
for builtins they're not processed until after each command finishes
executing [unless it does I/O with ztrapread/ztrapwrite]. For signals
like SIGINT, that when not trapped set flags which may cause commands to
be interrupted early, the behavior may become *very* different if the
trap is queued; consider:
trap 'trap - 2; kill -2 $$' 2
This is especially worrisome in non-interactive shells, which potentially
call ztrapread/ztrapwrite much less often. Consider too the number of
places where zsh does I/O with stdio functions, during which traps are
now (as of 13108) not executed.
} There's still one more problem, which is that it might be possible for a
} trap to get queued while it's not ignored, but then become ignored before
} the queue runs.
} I'm still a bit concerned that there's going to be a bad interaction between
} queued signals and queued traps.
This is what it comes down to: The problem only occurs with signals that
can arrive asynchronously. We already have the signal queueing code to
handle that case; if it needs to be applied more widely, we should do that,
but I no longer believe that a blanket trap-handler-queue is a good idea.
Bart Schaefer Brass Lantern Enterprises
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by: