User: Password:
|
|
Subscribe / Log in / New account

High- (but not too high-) resolution timeouts

High- (but not too high-) resolution timeouts

Posted Sep 4, 2008 17:44 UTC (Thu) by mezcalero (subscriber, #45103)
Parent article: High- (but not too high-) resolution timeouts

Using prctl() for a process-wide timer accuracy doesn't appear to be a good idea to me. In many RT apps you have both RT and non-RT threads. Usually only for the RT threads timer accuracy matters while the non-RT threads only do non-critical housekeeping work where accuracy really doesn't matter. Having a per-thread way to adjust timer accuracy seems more appropriate to me.


(Log in to post comments)

Speaking of prctl

Posted Sep 4, 2008 18:05 UTC (Thu) by quotemstr (subscriber, #45331) [Link]

Why do we use prctl at all anyway? Isn't adding a new prctl just a backdoor way of adding another system call? Doesn't the same argument against using ioctl for arbitrary functionality apply also to prctl?

Why not just add new system calls for new functionality?

Speaking of prctl

Posted Sep 4, 2008 18:15 UTC (Thu) by arjan (subscriber, #36785) [Link]

prctl()'s purpose is to get and set values/properties on a per thread basis.....

it's not nearly as much a blanket thing as ioctl() is.

Speaking of prctl

Posted Sep 5, 2008 15:40 UTC (Fri) by wahern (subscriber, #37304) [Link]

One nice thing about such interfaces is that you can usually check for the interface using the C preprocessor (i.e. "#if defined FD_CLOEXEC ... #elif defined HANDLE_FLAG_INHERIT ..."). For totally obscure non-portable interfaces, that's definitely a win, especially for those of us not willing to use autoconf (or unable, such as when porting to Visual Studio).

High- (but not too high-) resolution timeouts

Posted Sep 4, 2008 18:14 UTC (Thu) by arjan (subscriber, #36785) [Link]

prctl() works on a per thread basis.....


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds