Date: Tue, 12 Aug 1997 15:40:07 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Cc: terry@lambert.org, sos@sos.freebsd.dk, current@FreeBSD.ORG Subject: Re: siginterrupt (was Re: Error in sleep !) Message-ID: <199708122240.PAA08551@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.96.970813021100.848A-100000@lsd.relcom.eu.net> from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Aug 13, 97 02:14:42 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > The claim is that FreeBSD defaults have been brought into concordance > > with POSIX. And the man pages have not been updated. > > What POSIX says exactly about siginterrupt(3) and restartable syscalls? POSIX says that system calls will not be restarted by default (the historical System V behaviour for signals). Since siginterrupt isn't a POSIX function, POSIX says nothing about it. However, if a system claims to be a POSIX system, it must exhibit default POSIX behaviours. If FreeBSD has been updated to exhibit POSIX behaviour (the original poster was claiming it had been), then the signal and siginterrupt man pages, which claim historical BSD behaviour, are wrong. They should claim POSIX behaviour instead. In other words, if the default behaviour is BSD, the man pages are correct, and if the default behaviour is POSIX, the man pages are broken. > > To the original poster: > > > > The system call restart of a sleep(3) does *not* guarantee that the > > elapsed time is subtracted from the argument when the restart is > > initiated (ie: if you sleep for 2 of 3 seconds, get a signal, and > > restart, the restart will likely be for another 3 seconds -- not > > the remaining 1). So depending on this behaviour is probably an > > error, in any case. > > I still not understand why you decide to connect restartable syscalls with > sleep(3) implementation. Both old and new sleep(3) variants not depends on > restartable syscalls. By default, if you intentionally send a signal to sleep(1), then you exit the sigpause() that sleep(3) uses to implement the sleep (it is expecting SIGALRM, but *any* signal will wake it up. Even a signal whose sigaction is SIG_DFL). The problem is that if I send a normally ignored signal to sleep(1) after it goes to sleep but before the interval is expired, the sleep doesn't keep going. I don't know if restarting a shell sleep is really a big problem; the sending of signals seems like a non-op... unless he's doing ^T status reporting, maybe? Or resizing the window containing the shell? In any case, I'd say that there may be a problem in SIG_DFL delivery handling. I still don't have a good handle on exactly what he wants to have happen; I know the threads safe libc calls nanosleep() instead; I'm betting that he is notiing a discrepancy in the behaviour in sleep(1) because of a threaded libc, more than anything else? Anyway, this is too much time on this topic for me... 8-(. Regards, Terry Lambert terry@lambert.org --- 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?199708122240.PAA08551>