zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.auc.dk (Zsh hackers list)
Subject: Re: PATCH: Re: Allowing traps
Date: Wed, 22 Nov 2000 17:33:45 +0000	[thread overview]
Message-ID: <1001122173345.ZM12195@candle.brasslantern.com> (raw)
In-Reply-To: <1001120173911.ZM10192@candle.brasslantern.com>

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
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   


  reply	other threads:[~2000-11-22 17:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-20 16:09 Peter Stephenson
2000-11-20 16:34 ` Bart Schaefer
2000-11-20 16:54   ` Peter Stephenson
2000-11-20 17:39     ` PATCH: " Bart Schaefer
2000-11-22 17:33       ` Bart Schaefer [this message]
2000-11-23  8:11 Sven Wischnowsky
2000-11-23 19:14 ` Bart Schaefer
2000-11-23 21:42   ` Peter Stephenson
2000-11-23 21:58     ` Bart Schaefer
2000-11-23 22:05     ` Bart Schaefer
2000-11-24  8:06 Sven Wischnowsky

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=1001122173345.ZM12195@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).