[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 #16 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Stas Sergeev from comment #15)
> > Indeed afaik Linux reset the overrun time on each sigtimedwait syscall.
> 
> Its not linux, its posix who defined
> timer_getoverrun() in an entirely crazy
> way of measuring underruns between signal
> queue and dequeue.
> Linux is at least making this more or
> less viable by actually measuring between
> dequeues only.
> Linux itself clearly says how it see it
> implemented: timerfd, where read() just
> resets the overrun count. Linux is written
> by skilled programmers, while posix is
> written by a mediocre doc-writers.
> 
> > In fact, POSIX also advises against it on the timer_settime application
> > because of the concurrent stack usage issue [2].
> 
> Quote:
> 
> [EINVAL]
>     The it_interval member of value is not zero and the timer was created
> with notification by creation of a new thread (sigev_sigev_notify was
> SIGEV_THREAD) and a fixed stack address has been set in the thread attribute
> pointed to by sigev_notify_attributes.

This is defined as 'may fail', which does not bind the implementation to the
required semantic of one thread per time expiration.

> 
> So concurrent stack usage is explicitly
> disallowed, which means a detached thread
> per timer tick, as was said in the prev
> quote that I provided.
> 
> > But POSIX explicitly states that the thread is *not* joinable
> > ("In neither case is it valid to call pthread_join()")
> 
> I don't think it means not joinable.
> I think it means only that the _user_
> should never call pthread_join() on
> such thread. Presumably he could do
> that by exporting its pthread_self()
> through the global variable.
> I think the thread itself can be joinable,
> and as long as the user doesn't call
> pthread_join() on it, things are good
> and glibc itself *can* (and should)
> call pthread_join() internally on a
> timer destruction.

This wording is a user-visible API, so not being joinable it means that the
caller can not call any pthread interface meant for joinable threads (I think
POSIX is pretty clear in this regard).  As I said, making the thread joinable
implies a lot of caveats for the API, and that's why POSIX is explicit about
it.

And glibc does not need to join the thread, if it is created in detached mode
the thread itself will be responsible for handling any allocated resources and
an additional synchronization with any global state.

> 
> > In fact, from the Austin issue [1] the next POSIX 2018 defined that providing
> > a pthread_attr_t with joinable state is undefined-behavior [2];
> 
> This only confirms that posix is
> written by idiots. But such an obvious
> fact probably doesn't need so many
> confirmations. :)

Afaik POSIX only defines API after a de-facto implementation exactly to avoid
adding non-tested ones. But I would like to avoid bad-mouthing other groups in
bug reports.

> 
> > so I am even more inclined to *not* move to make it implementation-defined.
> 
> I am definitely not "insisting" in
> any way. I am only pointing out that
> any other approach is even more problematic.
> But at the end, any improvement is better
> than the current mess.
> 
> What do you think about opening a DR to
> The OpenGroup? If it would be me, I wouldn't
> resist saying who they are, so its better
> be you. :) Though I don't think timer_create()
> API can be vindicated by a DR or 2.
> getoverrun is also completely broken, and
> so on. Why I still have to use it, is only
> because of freebsd. On linux my app uses
> timerfd, of course and for sure. I am trying
> to avoid the brain-damaged posix APIs on
> linux, but there comes freebsd...

A DR for what exactly? I think the current definition does allow one-thread per
timer without extra thread per timer expiration (musl implements it and Rich is
*very careful* about following standards) so I don't see which additional
clarification we need on this topic.

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