From owner-freebsd-current Sun Dec 13 22:31:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA07180 for freebsd-current-outgoing; Sun, 13 Dec 1998 22:31:42 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA07036 for ; Sun, 13 Dec 1998 22:31:24 -0800 (PST) (envelope-from listuser@netspace.net.au) Received: from d1o1.telia.com (root@d1o1.telia.com [195.67.240.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id HAA08979 for ; Mon, 14 Dec 1998 07:27:39 +0100 (CET) Received: from doorway.home.lan (t6o1p59.telia.com [195.67.241.119]) by d1o1.telia.com (8.8.8/8.8.5) with ESMTP id HAA19389 for ; Mon, 14 Dec 1998 07:27:38 +0100 (CET) Received: (from listuser@localhost) by doorway.home.lan (8.8.8/8.8.7) id GAA08425 for freebsd-current@FreeBSD.org; Mon, 14 Dec 1998 06:55:16 +0100 (CET) (envelope-from listuser) Date: Mon, 14 Dec 1998 06:55:16 +0100 (CET) From: List User Message-Id: <199812140555.GAA08425@doorway.home.lan> To: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Newsgroups: freebsd.current Path: root From: Matthew Dillon Subject: Re: inetd: realloc/free bug Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id SAA07846; Sun, 13 Dec 1998 18:08:31 -0800 (PST) (envelope-from dillon) To: Terry Lambert Sender: owner-freebsd-current@FreeBSD.ORG Organization: Private News Host Precedence: bulk Message-ID: <199812140208.SAA07846@apollo.backplane.com> References: <199812132244.PAA10383@usr09.primenet.com> Delivered-To: vmailer-current@freebsd.org X-Uidl: 286bceb955549236b6e1d1cad241ea38 X-Loop: FreeBSD.ORG Cc: archie, jwd, freebsd-current Date: Mon, 14 Dec 1998 02:08:31 GMT I think there's some confusion here: The reason there is a timeout on the select has nothing to do with signals interrupting system calls. We don't care about that case - it's irrelevant. The only reason there is a timeout on the select is to handle the case where a signal occurs just *BEFORE* select() is entered where the signal function adds a file descriptor to the mask set. If this case occurs, the select() will wind up waiting on a mask set that does not contain the new descriptor thus possibly resulting in an infinite wait. That is the *SOLE REASON* why there is a timeout on the select. As I have said repeatedly: If someone does a read of the code and can guarentee that none of the signal functions *add* a descriptor to the mask set, we can remove the timeout entirely. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) :> :> If you put a time limit on select(), it doesn't matter if there is a :> :> race condition there. How does select() cause a signal to be missed ? :> : :> :Well, sure.. :-) but then you don't service signals in real time :> :and spend extra cycles timing out all the time. :> :> You do serve signals in real time... the signals are *unmasked* during :> the select() :-) ... the race condition is that the unmasked signal may :> cause the descriptor set to be changed just prior to the select() call, :> causing select() to wait forever. The timeout on the select() handles :> the race condition without effecting the realtime delivery of signals. : :You should just use siginterrupt(3) to make sure select restarts, and be :done with it. : :If you need to interrupt the select after setting system call restart :behaviour, then use a longjmp from the signal handler after setting a :volatile flag so that the flag can be tested in the "else" case of :the setjmp() call. : :If the call is restarted, you don't have to worry about the timer, it :will do the right thing, and you won't get an EINTR that you con't know :how to handle the masks around. : :If you don't like siginterrupt(3), and want to use the non-Berkeley :signal mechanisms for setting call restart behaviour, then be my :guest and write 30 or 40 lines of POSIX expecting code instead. : :The siginterrupt(2) system call first appeared in BSD 4.1c; the :current code uses POSIX sigaction(2); someone might want to correct :the siginterrupt(3) man page... : : : Terry Lambert : terry@lambert.org :--- :Any opinions in this posting are my own and not those of my present :or previous employers. : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-current" in the body of the message : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message