[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 #13 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Stas Sergeev from comment #12)
> > And since it is the kernel that keep track of the overrun, the reentrancy
> > issue is not really related on the overrun itself, but rather on the sigval
> > argument.
> 
> Overruns are measured between signal queue
> and dequeue. Linux fixes that scheme by
> actually measuring between 2 subsequent
> dequeues AFAIKS, though doesn't matter.
> What matters is that, because of reentrancy,
> the handler will query the overruns after
> another signal was already delivered, so
> the result would be a complete garbage.

Ok, I now see what you mean here. Indeed afaik Linux reset the overrun time on
each sigtimedwait syscall.  

> 
> > My understanding from the quote you borght is not that it is specified
> > that concurrent threads are allowed or not
> 
> Let me quote again then:
> [quote]
> the threads created in response to a timer expiration are created detached,
> or in an unspecified way if the thread attribute's detachstate is
> PTHREAD_CREATE_JOINABLE.
> [/quote]
> 
> Three things are being said here:
> 1. Threads are created in a response to every timer expiration

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].  So, the current scheme has the
additional drawback that a user-specific stack is really not safe.

> 2. They are detached
> 3. The user can specify PTHREAD_CREATE_JOINABLE, in which
> case the behavior is implementation-specific.
> 
> I propose to use 3 as a base for implementing
> PTHREAD_CREATE_JOINABLE case first, then see
> what remains.

But POSIX explicitly states that the thread is *not* joinable ("In neither case
is it valid to call pthread_join()"), and as I said it makes even tricker to
handle the per-timer thread (what happens to the timer after the thread is
joined? Should pthread_join issue timer_delete? What happens if there thread if
cancelled or issue pthread_exit?).

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
[2]
https://pubs.opengroup.org/onlinepubs/9699919799/functions/timer_settime.html

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