[Bug libc/30558] SIGEV_THREAD is badly implemented

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #18 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Stas Sergeev from comment #17)
> > 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".

I don't think so, the earlier quote (which you linked from the previous POSIX
version by the way, although it has not changed on POSIX 2017) allows both
implementations.  The timer_settime quote also only allows the implementation
to return an error if the resulting timer will trigger a UB (by using the same
stack on multiple threads), if the implementation is not subject to such issue
it can ignore the 'may fail'.

> 
> > 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.

Not being joinable means that calling pthread_join() is UB. Some
implementations *might* try to catch such issues (as glibc, since it keeps the
pthread_t stack in a cache for some time), but again it is error-prone and
fragile.

> 
> > And glibc does not need to join the thread
> 
> But we were discussing the user-provided
> PTHREAD_CREATE_JOINABLE attribute.

Which is overridden by an explicit __pthread_attr_setdetachstate
(PTHREAD_CREATE_DETACHED) on timer_create. Again, not doing this results in a
tricky implementation and I think we should not move toward it.

> 
> > 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.

Feel free to propose it, I think it would make some implementation
non-conformant and thus will most likely be either rejected or raised to amend
by some commenter. But again, the implementation with one thread per timer
should be conformant and improve current support for timer_overrun; so I see no
strong reason to ask for DR to tie POSIX timer SIGEV_THREAD to a specific
implementation that might not be the best approach.

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