Date: Thu, 27 Jan 2005 10:04:21 +0800 From: David Xu <davidxu@freebsd.org> To: "Christian S.J. Peron" <csjp@freebsd.org> Cc: arch@freebsd.org Subject: Re: resolver un-conditionally restarts interrupted kevent Message-ID: <41F84C25.60903@freebsd.org> In-Reply-To: <20050127012401.GB48521@freefall.freebsd.org> References: <20050127012401.GB48521@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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! >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41F84C25.60903>