From owner-freebsd-threads@FreeBSD.ORG Sat Oct 8 23:39:51 2005 Return-Path: X-Original-To: threads@freebsd.org Delivered-To: freebsd-threads@FreeBSD.ORG Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BA5CD16A41F; Sat, 8 Oct 2005 23:39:50 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <434858D0.1080308@freebsd.org> Date: Sun, 09 Oct 2005 07:40:00 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.10) Gecko/20050806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20051008105232.B84936@fledge.watson.org> In-Reply-To: <20051008105232.B84936@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , threads@freebsd.org Subject: Re: SIGINFO interrupts connect() with libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2005 23:39:51 -0000 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