profile-handler: prefer documented sigev_notify_thread_id in sigevent

[sgn]

sigevent(7) is documented to have sigev_notify_thread_id as its member.
In glibc system, it's a macro expanded to the legacy _sigev_un._tid,
_sigev_un._tid is obviously an internal implementation detail as
signaled by its underscore prefix.

On Linux that use musl libc, sigev_notify_thread_id is also a macro, but
it's expanded to __sev_fields.sigev_notify_thread_id

Let's use the documented member if exists with a fallback to the
undocumented member instead.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[sgn]

@googlebot I signed it!

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[alk]

Thanks for patch. glibc actually has sigev_notify_thread_id macro, but in linux/signal.h include. Notably musl doesn't seem to have this header. So perhaps we detect presence of linux/signal.h include it and use sigev_notify_thread_id for glibc too.

[alk]

Also BSD does support this macro too, using your existing include. So very nice. https://www.freebsd.org/cgi/man.cgi?query=sigevent&sektion=3&apropos=0

[sgn]

On 2021-02-12 22:29:20-0800, "Aliaksey Kandratsenka (aka Aliaksei Kandratsenka)" ***@***.***> wrote: Thanks for patch. glibc actually has sigev_notify_thread_id macro, but in linux/signal.h include. Notably musl doesn't seem to have this header. So perhaps we detect presence of linux/signal.h include it and use sigev_notify_thread_id for glibc too.

Sorry for being ignorance. But, what is your preference in this case: - rewrite this patch entirely: detect if linux/signal.h exists and include linux/signal.h and use sigev_notify_thread_id unconditionally - Write another patch on top of this patch?

[alk]

Hm, turns out linux/signal.h is basically unusable. It defines things that are conflicting with libc types (seeing this in both glibc and musl too). I've updated kernel bug at https://bugzilla.kernel.org/show_bug.cgi?id=200081

I think I'll take your change with minimal fix on top to unbreak it for glibc systems (since configure rightfully detects that linux/signal .h is broken and we end up with compile error trying to use that macro that is not defined anywhere). Your first change was most right one given that kernel headers bug.

[alk]

Filed glibc bug as well: https://sourceware.org/bugzilla/show_bug.cgi?id=27417

[alk]

Merged. Thanks a lot for the patch! Indeed musl compilation was borked without it. As noted above, I've amended your change. Making clear notice about this in commit message. Hope this is okay (I left authorship on you, but hopefully blames on bug(s) in this change I accepted on me).

[sgn]

Thanks.