About pthread_yield() implementation

About pthread_yield() implementation

[Rachid Koucha]

Hi,

Answering a question about pthread_yield() on StackOverflow web site, I
realize that there is a possible implementation bug for this function
(in the GLIBC 2.31 at least):

The source code of the service is:

|/* With the 1-on-1 model we implement this function is equivalent to
the 'sched_yield' function. */ int pthread_yield (void) { return
sched_yield (); } |

||||But this results in a unusual pthread API behavior which *may be an
implementation bug* as it returns directly the result of
/sched_yield()/. Like most of the Linux system calls, the latter returns
-1 and sets *errno* if it fails (even if the manual specifies that it
actually never returns in error). So, theoretically, this makes
/pthread_yield()/ return -1 and set *errno* in case of error although
the pthread API usually returns 0 if successful and the error number in
case of error (*errno* is not supposed to be set). So, the manual is
wrong or at least does not comply with the GLIBC's implementation when
it describes the returned value as:

RETURN VALUE

    On success, pthread_yield() returns 0; on error, it returns an error
    number.


Regards,

Rachid.


||

||

Re: About pthread_yield() implementation

[Adhemerval Zanella]

On 20/12/2020 16:03, Rachid Koucha via Libc-alpha wrote:
> Hi,
> 
> Answering a question about pthread_yield() on StackOverflow web site, I
> realize that there is a possible implementation bug for this function
> (in the GLIBC 2.31 at least):
> 
> The source code of the service is:
> 
> |/* With the 1-on-1 model we implement this function is equivalent to
> the 'sched_yield' function. */ int pthread_yield (void) { return
> sched_yield (); } |
> 
> ||||But this results in a unusual pthread API behavior which *may be an
> implementation bug* as it returns directly the result of
> /sched_yield()/. Like most of the Linux system calls, the latter returns
> -1 and sets *errno* if it fails (even if the manual specifies that it
> actually never returns in error). So, theoretically, this makes
> /pthread_yield()/ return -1 and set *errno* in case of error although
> the pthread API usually returns 0 if successful and the error number in
> case of error (*errno* is not supposed to be set). So, the manual is
> wrong or at least does not comply with the GLIBC's implementation when
> it describes the returned value as:
> 
> RETURN VALUE
> 
>     On success, pthread_yield() returns 0; on error, it returns an error
>     number.

Indeed, it should be calling thrd_yield through INTERNAL_SYSCALL_CALL
(similar to thrd_yield).  It should not happen in a realword because
the Linux syscall never fails, but it is worth to fix.  I will check
this out.