Date: Thu, 27 Jan 2005 01:24:01 +0000 From: "Christian S.J. Peron" <csjp@FreeBSD.org> To: arch@FreeBSD.org Subject: resolver un-conditionally restarts interrupted kevent Message-ID: <20050127012401.GB48521@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050127012401.GB48521>