Re: pthread_attr_setsched behaviour

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Apr 17, 2013 at 06:19:52PM +0530, Siddhesh Poyarekar wrote:
> On Tue, Apr 16, 2013 at 03:32:11PM +0200, Manuel Traut wrote:
> > Hi,
> > 
> > i just recognized, that calling:
> > 
> > ret |= pthread_attr_setschedpolicy (..)
> > ret |= pthread_attr_setschedparam (..)
> > ret |= pthread_create (..)
> > 
> > doesn't return an error and the values set by pthread_attr_setschedparam and
> > pthread_attr_setschedpolicy aren't applied to the thread.
> > 
> > The APPLICATION USAGE of the functions say:
> > 
> >    After  these attributes have been set, a thread can be created with the
> >    specified attributes using pthread_create(). Using these routines  does
> >    not affect the current running thread.
> > 
> > So I didn't expect that I need to call:
> > pthread_attr_setinheritsched before pthread_create.
> > 
> > I would like to improve the current behaviour, with a little patch;
> > please give me some directions...
> > 
> > Is there a reason why e.g. pthread_attr_set_schedparam doesn't set
> > iattr->flags |= ATTR_FLAG_NOTINHERITSCHED
> 
> The POSIX specification doesn't tell us that we ought to do this.  If
> we do, we might end up breaking compatibility.
> 
> > Or is it better to return an error code in pthread_attr_setschedparam, etc if
> > ATTR_FLAG_NOTINHERITSCHED isn't set?
> 
> This is wrong since one is allowed to set NOTINHERITSCHED after
> setschedparam.
> 
> > If both is bad, at least the man page should mention the need of calling
> > pthread_attr_setinheritsched..
> 
> This is the best option currently.  I've added Michael Kerrisk to cc;
> he maintains the man pages.

Indeed, all you can do is update the documentation. The specification
for these functions is clear; setting one attribute does not
implicitly set another. Moreover, for cases like this where
well-meaning people go and say "well it's not explicitly forbidden, so
why can't we do it?", the committee is in the process (maybe finished
now?) of adopting language to make it clear that interfaces in the
standard cannot have side effects that alter the state of the program
outside what they're specified to do, except in certain limited ways.
As a good example of what I mean, read() cannot zero the remainder
beyond the length it returns.

Rich