Date: Sun, 2 Sep 2007 00:40:26 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Joe Marcus Clarke <marcus@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: Understanding interrupted system calls Message-ID: <20070901224025.GA97796@stack.nl> In-Reply-To: <1188660782.41727.5.camel@shumai.marcuscom.com> References: <1188600721.1255.11.camel@shumai.marcuscom.com> <20070901112600.GA33832@stack.nl> <1188660782.41727.5.camel@shumai.marcuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 01, 2007 at 11:33:02AM -0400, Joe Marcus Clarke wrote: > However, I'm curious as to my other point in this thread. Why should > one need to re-register the default signal handlers to get a syscall to > return EINTR? Or should ERESTART be caught and turned into EINTR then > return to the caller (as in kern_connect())? It is intended that most blocking system calls are not interrupted by signals. This saves the programmer some checks on EINTR. (Note that this is only really useful if the program uses signal handlers which do something meaningful other than setting a flag or doing some simple cleanup and terminating the process. Such signal handlers are rarely safe.) Some system calls, e.g. connect(), read/write/etc that have already committed some data and under BSD also select/poll/kqueue do not restart and always return EINTR or partial success. In the kernel code, this appears as changing ERESTART to EINTR. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070901224025.GA97796>