| |||||||||||||
Speaking of prctlSpeaking of prctlPosted Sep 4, 2008 18:05 UTC (Thu) by quotemstr (subscriber, #45331)In reply to: High- (but not too high-) resolution timeouts by mezcalero Parent article: High- (but not too high-) resolution timeouts
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?
(Log in to post comments)
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).
|
|||||||||||||