Implement PosixSignal API

[tmds]

Implements #50527.

I still need to add tests.

Can you do a first review of the implementation?

cc @janvorli@jkotas@stephentoub@davidfowl@bartonjs

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[tmds]

I've manually added these to the ref file, I don't know if there is an automated way.

[jkotas]

The automated way is documented in https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/updating-ref-source.md . It would be a good idea to rerun the automated process to make sure that the formatting is right.

[davidfowl]

But beware, it currently removes attributes...

[tmds]

I ran it and copied in the PosixSignal bits.
I'm surprised to see internal instead of private on the PosixSignalRegistration constructor.

[andyleejordan]

Hey, I just wanted to drop by and say it's really exciting to see this work! 🥳

[tmds]

The implementation has changed a bit since the initial PR.

• Positive PosixSignal values can now be used as raw signal numbers.
• Terminal configuration on SIGCONT/SIGCHLD can be canceled, as requested by @alexrp.

The implementation will call the original sa_handler/sa_sigaction if one was set.

It handles specifically what is cancelable by the runtime using PosixSignal API:

• Not terminating for SIGTERM/SIGINT/SIGQUIT
• Skipping terminal configuration for SIGCHLD/SIGCONT.

I'll look at writing some tests next week.

[alexrp]

Just posting here as well so it doesn't get missed: I think it's worth considering a rename to UnixSignal for consistency reasons; see this comment.

[lambdageek]

@tmds what's the expected behavior if users set up a handler for a signal that the runtime uses internally.

For example, the mono GC uses signals on non-Apple Unixes to suspend threads that are in preemptive mode - we pick the signal dynamically and use pthread_kill for signalling.

runtime/src/mono/mono/utils/mono-threads-posix-signals.c

Lines 48 to 119 in f37f0b9

	staticintsuspend_signal_num=-1;
	staticintrestart_signal_num=-1;
	staticintabort_signal_num=-1;
	staticsigset_tsuspend_signal_mask;
	staticsigset_tsuspend_ack_signal_mask;
	staticvoid
	signal_add_handler (intsigno, void (*handler)(int, siginfo_t*, void*), intflags)
	{
	structsigactionsa;
	intret;
	sa.sa_sigaction=handler;
	sigfillset (&sa.sa_mask);
	sa.sa_flags=SA_SIGINFO | flags;
	ret=sigaction (signo, &sa, NULL);
	g_assert (ret!=-1);
	}
	staticint
	abort_signal_get (void)
	{
	#if defined(HOST_ANDROID)
	returnSIGTTIN;
	#elif defined (__OpenBSD__)
	returnSIGUSR1;
	#elif defined (SIGRTMIN)
	staticintabort_signum=-1;
	if (abort_signum==-1)
	abort_signum=mono_threads_suspend_search_alternative_signal ();
	returnabort_signum;
	#elif defined (SIGTTIN)
	returnSIGTTIN;
	#else
	g_error ("unable to get abort signal");
	#endif
	}
	staticint
	suspend_signal_get (void)
	{
	#if defined(HOST_ANDROID)
	returnSIGPWR;
	#elif defined (SIGRTMIN)
	staticintsuspend_signum=-1;
	if (suspend_signum==-1)
	suspend_signum=mono_threads_suspend_search_alternative_signal ();
	returnsuspend_signum;
	#else
	#if defined(__APPLE__) || defined(__OpenBSD__) || defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
	returnSIGXFSZ;
	#else
	returnSIGPWR;
	#endif
	#endif
	}
	staticint
	restart_signal_get (void)
	{
	#if defined(HOST_ANDROID)
	returnSIGXCPU;
	#elif defined (SIGRTMIN)
	staticintrestart_signum=-1;
	if (restart_signum==-1)
	restart_signum=mono_threads_suspend_search_alternative_signal ();
	returnrestart_signum;
	#else
	returnSIGXCPU;
	#endif
	}

Should we have some mechanism that the runtime could use to prevent users from installing handlers for these signals?

[tmds]

what's the expected behavior if users set up a handler for a signal that the runtime uses internally.

By default the original handler gets called.
That should make most signals work. Some won't work, because they need some more specific handling.

Should we have some mechanism that the runtime could use to prevent users from installing handlers for these signals?

I don't have a strong opinion if we should forbid certain values.
When using raw signal numbers, the user should know what he is doing.

[tmds]

CI fail is unrelated.

[stephentoub]

Thanks!