linux-kernel - Re: Correct way for an application to sleep?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 2 Mar 2007 02:43:41 +0100 (MET)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Sindre Aamås <aamas@...d.ntnu.no>
cc:	linux-kernel@...r.kernel.org
Subject: Re: Correct way for an application to sleep?

On Feb 24 2007 21:54, Sindre Aamås wrote:
>
>Without root-privilegies, that leaves general purpose sleep functions  
>like nanosleep afaik. The problem is that the granularity of these  
>seems very unpredictable, and if I am to use a lowest common  
>denominator I'd only be able to sleep like 10 ms pr 16.7 ms on fast  
>systems, and not at all on not so fast systems. So, I'd like to know  
>what the "correct" way to handle this kind of situation is, if any,  
>from a kernel perspective. Is the only sensible thing to do to give a  
>user settable preference, deciding on a compromise default (or one  
>that says "screw you old kernels")?

You could use an adaptive sleeping ('overhead-corrected'), but I do not 
know how well it works with asynchronous events (such as audio output).
Take a look at the usleep_ovcorr() function in
http://ttyrpld.svn.sf.net/viewvc/*checkout*/ttyrpld/trunk/user/replay.c

Jan
-- 
ft: http://freshmeat.net/p/chaostables/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/