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

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.

> 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. :)

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

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