Date: Thu, 20 Apr 95 12:02:24 MDT From: terry@cs.weber.edu (Terry Lambert) To: rw@namu01.gwdg.de (Rainer Wittmann UMS) Cc: bugs@FreeBSD.org Subject: Re: signal handling bug Message-ID: <9504201802.AA25748@cs.weber.edu> In-Reply-To: <9504201250.AA26059@namu01.gwdg.de> from "Rainer Wittmann UMS" at Apr 20, 95 02:50:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Any unix system, I know, except FreeBSD 2.0, behaves as follows, > if a process is reading from a slow device like standard input from > a terminal. If this process receives a signal, for which a signal > handler was installed by the process, then immediately control > is tranferred to the signal handler (FreeBSD does this as well). > After the signal was serviced, the read system call is termianted > and errno is set to EINTR. Rather then doing this, FreeBSD completes > the read system call, as if no signal would have arrived. This > misbehavior breaks some of may programs. No matter, how often > it gets a signal. It NEVER sets errno to EINTR. This behavior > also contradicts the man page of read. This is legacy BSD. Look at the siginterrupt() man page. This will cause the behaviour you desire. Or you can explicitly request the behaviour in the masking with the POSIX interface. I think that interrupting the system call is a scary default, since it means all system calls and all system calls in libraries that are in function that you don't know contain system calls will also need to be "restart wrapped". There is a lot of code to use longjmp to get around the problem and actually interrupt the system call -- this is legacy code for BSD systems. The initial introduction of siginterrupt(0 was, i believe, in DEC Ultrix 4.1 Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504201802.AA25748>