From owner-freebsd-hackers Tue Apr 20 3:23:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id 7D97814EA6 for ; Tue, 20 Apr 1999 03:23:10 -0700 (PDT) (envelope-from gram@cdsec.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.9.3/8.9.3) id MAA22200 for ; Tue, 20 Apr 1999 12:20:43 +0200 (SAST) Received: by citadel via recvmail id 22140; Tue Apr 20 12:20:25 1999 Message-ID: <371C5501.3AA0A34@cdsec.com> Date: Tue, 20 Apr 1999 12:20:49 +0200 From: Graham Wheeler X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 2.2.8-RELEASE i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: Using select() to implement a delay References: <199904200945.LAA28715@bowtie.nl> <371C53FE.3CE190C9@cdsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marc van Kempen wrote: > > > Hi all > > > > I have an interesting problem. I have a routine to implement delays: > > > > void Sleep(int secs, int usecs = 0) > > { > > struct timeval tv; > > tv.tv_sec = secs; > > tv.tv_usec = usecs; > > (void)select(0, 0, 0, 0, &tv); > > } > > > > I am using this both because it gives better resolution than sleep(), > > and also because it doesn't require the use of SIGALRM, while I am > > using elsewhere. > > > > On my development machine, Sleep(60) does exactly what is expected. On > > my clients machine, Sleep(60) returns immediately. Both are running > > FreeBSD 2.2.7. I don't have access to the clients machine, which is > > in another city, and has no development environment, so I can't run gdb, > > although it may not give away anything in any case. > > > > Does anyone have any ideas why the one works and the other doesn't? > > > > Did you try catching the return value from select, it might be getting a > signal. I'm starting to suspect that this is the case, and that the signal is SIGCHLD. The process does spin off child processes, and there may be some reason why these are terminating almost immediately on the client's system but running to completion on ours. This seems like the only sensible explanation that I can think of. It means there is still a problem, but that it is nothing strange to do with select itself. I didn't consider this a possibility at first because of the consistent difference in behaviour; I would have expected the SIGCHLDs to have a more erratic effect. I've put some debug logs in the SIGCHLD handler, so I should have confirmation within about half an hour. -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Internet/Intranet Network Specialists Data Security Products WWW: http://www.cdsec.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message