[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 #11 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Stas Sergeev from comment #10)
> > I don't see any reentrancy issue with the current approach
> 
> But there is.
> Its trivial to verify with your
> own test-case posted here. You just
> need to insert sleeps into the handler.
> 
> Which is why I made the above quote
> from posix. It says explicitly that
> a detached thread is created in response
> to every timer expiration.
> So it explicitly allows reentrancy and
> deliberately breaks timer_getoverrun(),
> and glibc was following that very precisely.

Ah right, indeed current approach will trigger the callback function with
provided arguments on each timer expiration while the new scheme will only
issue the callback once the previous timer callback returns.  Afaiu, POSIX does
not specify an semantic regarding it; it only specify that you need an overrun
facility that you can query. 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.

My understanding from the quote you borght is not that it is specified that
concurrent threads are allowed or not, but rather that if the application
allocates some memory to use as the thread stack it can not be reliably free
since the thread is not joinable (it will eventually leak once timer_delete is
called). 

And I don't think allowing the SIGEV_THREAD thread as joinable is also a good
way forward. Besides breaking the standard, it means that timer_delete is not
the only point where you cancel the timer (worse, the kernel will continue to
trigger the timer since in this case there is no timer_delete syscall on the
timer). We can add the timer_delete on thread exit / join, but the idea of the
per-thread timerid is that is only visible for the POSIX timer threads (pthread
code does not handle it).

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