From owner-freebsd-arch@FreeBSD.ORG Thu Jan 27 01:57:06 2005 Return-Path: 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 0A95416A4CE; Thu, 27 Jan 2005 01:57:06 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBEB143D1F; Thu, 27 Jan 2005 01:57:05 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0R1v3GI055174; Thu, 27 Jan 2005 01:57:04 GMT (envelope-from davidxu@freebsd.org) Message-ID: <41F84C25.60903@freebsd.org> Date: Thu, 27 Jan 2005 10:04:21 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christian S.J. Peron" References: <20050127012401.GB48521@freefall.freebsd.org> In-Reply-To: <20050127012401.GB48521@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 01:57:06 -0000 Christian S.J. Peron wrote: > 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? Because they can not be simply restarted. those interfaces have in/out parameters which may already be changed by kernel before returning, also a timeout wait can not be restarted, you told kernel to sleep 10 minutes, and at minute 9, it gets a signal and is restarted, it will return to user code after totally 19 minutes. > 2) why do we unconditionally restart kevent in our > resolver code? > I think that's right because the code checks 'n < 0' first, it got nothing and does timeout calculation by itself, that's OK. > Any insight would be great, thanks! >