[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 #9 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Stas Sergeev from comment #8)
> Great news, thanks!.
> So within this RFC may I use the
> timer_getoverrun() safely? I suppose
> so, because there seem to be no more
> reentrancy into the handler ever possible,
> and also no one will call sigwaitinfo()
> until the handler is finished. That
> seems to be enough for timer_getoverrun()
> to work reliably.

I don't see any reentrancy issue with the current approach, the background
thread that issues sigwaitinfo is created with only SIGSETXID not masked.  So
each sigwaitinfo will get one SIGTIMER from the kernel.

My RFC, on the other hand, requires installing the SIGCANCEL handler.  It works
because pthread_cancel does not actively sends the signal if the asynchronous
mode is not set (I might revise if this work for my proposed fix for BZ#12683).

> 
> Also I think the signal-related problems
> are not available as internally SIGEV_THREAD_ID
> is used, so I suppose every thread
> receives only the signal from its own
> timer. So indeed such impl seems to mostly
> match what can be done with timerfd.
> 
> > The glibc allows the created thread to be cancellable or call pthread_exit,
> > and it is not fully specified how the POSIX timer should act in this case.
> 
> Maybe you can assign the thread
> destructor with pthread_key_create(),
> which would then re-create a thread?

It would mean maintaining a list of SIGEV_THREAD timer_t so it updates the
relation of timer_t -> kernel timer_t on each thread recreation. It would not
be possible to use the pthread_t as the key for timer_* operation, so we will
always need to consult the data structure in such cases. I still prefer to musl
solution to intercept pthread_exit/pthread_cancel and do not act upon it.


> But there is more to it actually...
> https://pubs.opengroup.org/onlinepubs/007904975/functions/timer_create.html
> Quote:
> 
> If a timer is created which has evp->sigev_sigev_notify set to SIGEV_THREAD
> and the attribute pointed to by evp->sigev_notify_attributes has a thread
> stack address specified by a call to either pthread_attr_setstack() or
> pthread_attr_setstackaddr(), the memory dedicated as a thread stack cannot
> be recovered. The reason for this is that 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.
> 
> From here we see that posix actually
> enforces the current glibc behavior,
> except when PTHREAD_CREATE_JOINABLE
> is specified via evp->sigev_notify_attributes.
> One way to do the job, retain the full
> compatibility and posix compliance, is
> to actually implement a proper way of
> handling PTHREAD_CREATE_JOINABLE case.
> Which would be only 1 joinable thread.
> 
> Of course posix specifies timer_create()
> with multiple breakages, so what you do
> (ignore posix) is also perfectly reasonable
> in my eyes.
> 
> Whatever way you choice, it would be
> good to write that posix are moro...
> to open a DR to The OpenGroup.

In fact, POSIX defines a semantic that is not what glibc provides since calling
pthread_cancel on a detached thread is not really specified.  One option is
bring this on patch to state that trying to cancel the POSIX timer thread is
UB, so we should not really support it.

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