From owner-freebsd-arch Mon Feb 5 17:50:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id C898437B503 for ; Mon, 5 Feb 2001 17:50:00 -0800 (PST) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f161nrX19195; Mon, 5 Feb 2001 17:49:53 -0800 From: "Jonathan Graehl" To: "Jonathan Lemon" Cc: Subject: RE: nonblocking sockets and EINTR (kevent does not observe SA_RESTART?) Date: Mon, 5 Feb 2001 17:50:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20010205193507.J650@prism.flugsvamp.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I assume, then, that you guarantee that the changelist is applied (and errors relating to the changes are placed in the received-events-buffer, if possible) before the call becomes interruptible? (and if there were an error that doesn't fit in the buffer, the return would be immediate with the error code); that is, only after the process goes to sleep waiting in kqueue, is there the possibility of an EINTR return? Or, is there the possibility of the changelist only being partially executed when the result is EINTR? I concur that the EINTR semantics are simple and consistent, but perhaps a warning, to the effect that SA_RESTART does not prevent the EINTR outcome, is in order (this may be the case for quite a few other syscalls as well, I have no idea ... but it would be nice to see it documented) > The difficulty in restarting the kevent call is that it would have > to re-apply the changelist, which is probably not what you want. The > only case where it is possible to perform a restart is with an empty > changelist. I didn't put this optimization in, as I think it would be > better if the interface was consistent in all cases. > -- > Jonathan > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message