Re: resolver un-conditionally restarts interrupted kevent

From: David Xu (davidxu_at_freebsd.org)
Date: 01/27/05

  • Next message: Christian S.J. Peron: "Re: resolver un-conditionally restarts interrupted kevent" 
    Date: Thu, 27 Jan 2005 10:04:21 +0800
To: "Christian S.J. Peron" <csjp@freebsd.org>

    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!
    >

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Christian S.J. Peron: "Re: resolver un-conditionally restarts interrupted kevent"