[Bug libc/30558] SIGEV_THREAD is badly implemented

["stsp at users dot sourceforge.net" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #8 from Stas Sergeev <stsp at users dot sourceforge.net> ---
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.

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

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