Date: Sun, 09 Oct 2005 07:40:00 +0800 From: David Xu <davidxu@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Daniel Eischen <deischen@freebsd.org>, threads@freebsd.org Subject: Re: SIGINFO interrupts connect() with libpthread Message-ID: <434858D0.1080308@freebsd.org> In-Reply-To: <20051008105232.B84936@fledge.watson.org> References: <Pine.GSO.4.43.0510071222570.15511-100000@sea.ntplx.net> <20051008105232.B84936@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > > On Fri, 7 Oct 2005, Daniel Eischen wrote: > >> On Thu, 6 Oct 2005, Robert Watson wrote: >> >>> I was writing test tools yesterday, and was a bit surprised to find >>> that hitting ctrl-T interrupts connect() for applications linked >>> against libpthread(). I wrote a simple test tool and found that >>> this is not the case for any of the other thread libraries (which >>> seems correct to me). Test tool attached: >> >> >> This isn't a problem with libpthread. If you install a signal >> handler for SIGINFO in your application with sa_flags = SA_RESTART, >> it gets interrupted even when just linked with libc. > > > Unlike, say, an I/O operation, the notion of restarting a connect() > system call is fairly fraught with peril. Normally, attempts to call > connect() on a socket that is already in the process of connecting > will return EALREADY, since you don't want to further frob the > protocol state machine. A bit of googling suggests that Stephens talks > about this in some detail, pointing out that in the EINTR case, the > application will really need to select() for the socket becoming > writable in order to wait for the connection attempt to finish (or > fail). While a bit awkward for the application, it appears these are > not uncommon semantics for the system call, and suggest the perils of > using blocking I/O with signals are significant. Unfortunately, the > problem with this libpthread feature is that, unlike our other thread > libraries, it exposes the application to this peril even if the > application itself doesn't actively use signals. > > Is your suggestion that connect() should detect an attempt to connect > to the same host and "continue where it left off"? POSIX tells us > that EALREADY should be returned if that is attempted: > > [EALREADY] > A connection request is already in progress for the specified socket. > Unfortunately, it is not stable to use errno, problem is many programmers do not preserve errno in signal handler, so after the signal handler did a failure syscall, the errno must not be EALREADY, although I know libpthread has code to protect errno in signal handler, but not other thread libraries, this is also not a portable feature. :-) David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?434858D0.1080308>