From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 25 09:39:37 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 333E316A401 for ; Mon, 25 Feb 2008 09:39:37 +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 BF19C13C45A for ; Mon, 25 Feb 2008 09:39:36 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from [192.168.1.38] (a89-182-20-101.net-htp.de [89.182.20.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id CC79BA44529 for ; Mon, 25 Feb 2008 10:39:34 +0100 (CET) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: freebsd-hackers@freebsd.org Date: Mon, 25 Feb 2008 10:39:59 +0100 User-Agent: KMail/1.9.7 References: <200802221558.42443.sharadc@in.niksun.com> <200802221437.48293.wundram@beenic.net> <200802251440.56435.sharadc@in.niksun.com> In-Reply-To: <200802251440.56435.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: <200802251039.59767.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: Mon, 25 Feb 2008 09:39:37 -0000 Am Montag, 25. Februar 2008 10:10:56 schrieb Sharad Chandra: > So does it mean, freebsd has limitation. sleeping will only work for its > value more than 1 milli sec because % of +- error value is comparitivly > low? I am curious to know, is there any method which sleeps for few > microseconds. Some one please give me link where to look for "select". No, this does not mean that FreeBSD has a limitation, but rather that FreeBSD is not a real-time operating system. You'll see the similar behaviour on pretty much any other operating system that is _not_ a RTOS (for example, Windows has a fixed resolution of non-Multimedia-Timers of around 10ms [where Multimedia Timers are a specific interface to sleep with a higher resolution, designed for Multimedia applications, but the resolution isn't that much higher, anyway], and on Linux, it also depends on the Tick-Frequency, similar to FreeBSD's HZ setting, but actually I don't know how the tickless Linux-kernel [which is implemented only in the latest versions, and not default anyway] behaves here). There is no way (AFAIK) for a userland application to _sleep_ for a finer grained amount of time than a timeslice, except in a busy loop which calls gettimeofday or similar repeatedly to break when the "timeout" occurs, but even then you don't have a guarantee that you won't sleep longer, simply because the process might be preempted just before the timeout occurs because another process also wants its timeslice. But, more specifically, why do you need to sleep for a short time in a user process anyway? Normally, you're blocking on some form of condition, which will "wake you up" as soon as the condition triggers and you can be scheduled (and in this "active scheduling" case the time-slice "rule" doesn't apply). If you give some more info on what you're trying to do (and why you need such a high resolution sleep), maybe someone will be able to help you better and show you how to achieve what you're trying to do without blocking on a timeout. -- Heiko Wundram Product & Application Development