From owner-freebsd-arch@FreeBSD.ORG  Thu Jan 27 01:24:01 2005
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id A023516A4D0; Thu, 27 Jan 2005 01:24:01 +0000 (GMT)
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 8966343D2D; Thu, 27 Jan 2005 01:24:01 +0000 (GMT)
	(envelope-from csjp@FreeBSD.org)
Received: from freefall.freebsd.org (csjp@localhost [127.0.0.1])
	by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0R1O1Da053337;
	Thu, 27 Jan 2005 01:24:01 GMT
	(envelope-from csjp@freefall.freebsd.org)
Received: (from csjp@localhost)
	by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0R1O1Co053336;
	Thu, 27 Jan 2005 01:24:01 GMT
	(envelope-from csjp)
Date: Thu, 27 Jan 2005 01:24:01 +0000
From: "Christian S.J. Peron" <csjp@FreeBSD.org>
To: arch@FreeBSD.org
Message-ID: <20050127012401.GB48521@freefall.freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Subject: resolver un-conditionally restarts interrupted kevent
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 01:24:01 -0000

Hey

I've noticed kind of an anoying feature with our resolver. It
seems that if a process recieves a signal while waiting for a
DNS response, kevent(2) will fail returning EINTR which sounds
right. However I also noticed this:

                        n = _kevent(kq, &kv, 1, &kv, 1, &ts);
                        if (n < 0) {
                                if (errno == EINTR) {
                                        (void) gettimeofday(&ctv, NULL);
                                        if (timercmp(&ctv, &timeout, <)) {
                                                timersub(&timeout, &ctv, &ctv);
                                                TIMEVAL_TO_TIMESPEC(&ctv, &ts);
                                                goto wait;

Which un-conditionally restarts kevent(2) in the event of a signal.
Logic tells me that the right way to do this would be to have the
process set SA_RESTART when it registers a signal handler, and have
kevent return ERESTART and IF kevent returns ERESTART, restart the
signal.

After further investigation into our multiplexing mechanisms like
poll, select and kevent explicitly change ERESTART to EINTR.

                /* don't restart after signals... */
                if (error == ERESTART)
                        error = EINTR;
                else if (error == EWOULDBLOCK)
                        error = 0;
                goto done;

So I guess I have two questions

	1) why do we explicitly change ERESTART to EINTR?
	2) why do we unconditionally restart kevent in our
	   resolver code?

Any insight would be great, thanks!

-- 
Christian S.J. Peron
csjp@FreeBSD.ORG
FreeBSD Committer