zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: zsh-3.1.9-dev-6 crashes occassionally
Date: Tue, 31 Oct 2000 16:42:22 +0100 (MET)	[thread overview]
Message-ID: <200010311542.QAA01070@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Tue, 31 Oct 2000 15:25:52 +0000


Bart Schaefer wrote:

> On Oct 31,  1:51pm, Peter Stephenson wrote:
> } Subject: Re: zsh-3.1.9-dev-6 crashes occassionally
> }
> } Sven wrote:
> } > +	ALLOWTRAPS {
> } > +	    while ((r = read(SHTTY, &cc, 1)) != 1) {
> } 
> } I suppose you've thought this through more than I have, but wouldn't it be
> } safer just to run traps every time the read returns?  I'm assuming a signal
> } arriving will interrupt the read in any case, so as far as I can see it's
> } pretty much equivalent in practise.
> 
> On Oct 31,  3:01pm, Sven Wischnowsky wrote:
> }
> } Unless someone knows of a system where signals don't interrupt things
> } like read.
> 
> Ever heard of BSD restartable system calls?

Yes, of course. But we set S[AV]_INTERRUPT on our signal handlers, so...

> Signals don't always interrupt things like read.  On systems that have
> the sigaction() interface, you can choose to turn restartable-ness on and
> off, but on an older BSD system the only way out of a system call from a
> signal handler is with setjmp/longjmp. 

...are there still such systems? Hm.

Anyway, the way the patch handles this should be ok, because (if I've
found all the places where a possibly blocking system call is made)
traps are called during such system calls.

> That's what I was talking about
> before in my last message.

Aha, I admit I was wondering... No, I definitely think we shouldn't
even start to think about using that as long as the way the patch
handles it works. If it works.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


             reply	other threads:[~2000-10-31 15:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-31 15:42 Sven Wischnowsky [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 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-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
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=200010311542.QAA01070@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --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).