[mono] Propagate pthread_kill EAGAIN to thread suspend initiator (remove workaround)

[lambdageek]

In #32377 (comment) we observed that in many test runs on Helix the GC STW will send out suspend signals with pthread_kill and get back an error EAGAIN which indicates that the realtime signal queue was full.

The temporary workaround #33966 that was put in place in the low-level code was to sleep for some number of milliseconds and retry some fixed number of times.

We should instead investigate:

• Why does the signal queue become full? Is this some pathological behavior of Mono's STW or an external stimulus?
• Can we deal with suspend failures in a more general way by propagating an error code from mono_threads_suspend_begin_async_suspend to the suspend initiator so that the suspend initiator can take some action.

[SamMonoRT]

@lambdageek - is the temporary workaround you merged good enough, or should we consider this for 8.0 and/or close this issue ? Not seeing any more reported CI failures initially linked to the issue.

[lambdageek]

I think we can close the issue. I think this issue is quite artificial in practice, and the retry workaround is actually pretty reasonable.

[tmds]

@lambdageek the issue title makes me think of #77364. Could they be related?

[lambdageek]

@lambdageek the issue title makes me think of #77364. Could they be related?

@tmds I don't think they're related directly. In #33966 we are working around the GC suspend initiator getting an unusual errno value. In this #77364, it's seems like it is other threads that leak an errno from some of the runtime machinery into the interop layer and then into managed code.

I suppose it is possible that a thread in 77364 is the suspend initiator. Although the hack in 33966 added a warning that should be visible on stderr if we this piece of the suspend code is getting EAGAIN.

It's possible that more libc functions or syscalls on Linux set errno to EAGAIN when it's not documented, so the issues could be related in a general sense.