From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 13:37:32 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6C4B16A400 for ; Fri, 22 Feb 2008 13:37:32 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id B30C513C45B for ; Fri, 22 Feb 2008 13:37:32 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from [192.168.1.38] (a89-182-150-142.net-htp.de [89.182.150.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id A41EAA44529 for ; Fri, 22 Feb 2008 14:37:30 +0100 (CET) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: freebsd-hackers@freebsd.org Date: Fri, 22 Feb 2008 14:37:48 +0100 User-Agent: KMail/1.9.7 References: <200802221558.42443.sharadc@in.niksun.com> In-Reply-To: <200802221558.42443.sharadc@in.niksun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802221437.48293.wundram@beenic.net> Subject: Re: usleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 13:37:33 -0000 Am Freitag, 22. Februar 2008 11:28:42 schrieb Sharad Chandra: > Does usleep work for you? i just saw it is implemented over nanosleep > which passes a struct timeval to "select". Quoting from POSIX: """ The usleep() function will cause the calling thread to be suspended from execution until either the number of real-time microseconds specified by the argument useconds has elapsed or a signal is delivered to the calling thread and its action is to invoke a signal-catching function or to terminate the process. The suspension time may be longer than requested due to the scheduling of other activity by the system. """ See the last sentence, specifically. So, yes, the behaviour you're seeing is pretty much expected, simply because _user_ processes are scheduled in timeslices, which depend on the HZ setting of the kernel. -- Heiko Wundram Product & Application Development