[Bug libc/30558] SIGEV_THREAD is badly implemented

["stsp at users dot sourceforge.net" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30558

--- Comment #17 from Stas Sergeev <stsp at users dot sourceforge.net> ---
> This is defined as 'may fail', which does not bind the implementation
> to the required semantic of one thread per time expiration.

Still it is enough to make your other
claim invalid:

"Reading the SIGEV_THREAD description [1], it is not clear to me that a new
thread should be created for *every* timer expiration from the same timer.
In fact, POSIX also advises against it on the timer_settime application because
of the concurrent stack usage issue [2]."

The earlier quote provided by me
is very explicit on a thread per tick,
and timer_settime doesn't advice against
that because it even defines the failure
per multiple stack usage. This means it
foresee 1 detached thread per tick, rather
than advicing against.
So we have 1 explicit quote about that,
and we have 1 that implicitly supports
that. I'd say "posix is very clear on this".

> This wording is a user-visible API, so not being joinable

There is no such wording.
The wording it:
"In neither case is it valid to call pthread_join()"
and you conclude it means not joinable.
But it doesn't mean so.

> And glibc does not need to join the thread

But we were discussing the user-provided
PTHREAD_CREATE_JOINABLE attribute.

> Afaik POSIX only defines API after a de-facto implementation
> exactly to avoid adding non-tested ones.

Maybe that was modeled after some very
old bsd impl, no idea. Linux would definitely
not start from such an impl. It is visibly
even trying to fix timer_getoverrun()'s
definition, and then re-implements the whole
thing in a timerfd.

> A DR for what exactly?

Exactly for proposing 1 detached thread
per tick in the quote I pointed. And there
were no quotes that say otherwise.
Also they should explicitly disallow
calling pthread_exit() and other things
that musl disallow.
Also they should realize that 1 thread
per tick breaks timer_getoverrun(), and
probably re-spec timer_getoverrun()
completely.
Or if they fail to do the above, then
at least they should keep supporting
passing a pthread attribute, rather
than to declare that an UB (although
this is not needed if they fix the rest).
There are the reasons for a DR here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.