msgq receive replaces signal handlers

[sshane]

This basically never allows ExitHandler to see signals, needed for commaai/openpilot#32103

msgq/msgq/impl_msgq.cc

Lines 79 to 82 in 5bb86f8

	if (!non_blocking){
	prev_handler_sigint = std::signal(SIGINT, sig_handler);
	prev_handler_sigterm = std::signal(SIGTERM, sig_handler);
	}

[sshane]

@deanlee want to check this out? Can we just forward to the prev signal handlers in msgq's signal handler?

[deanlee]

Forwarding signal handlers isn’t ideal because it introduces complexity and requires careful management of race conditions when restoring original handlers in multi-threaded environments.

A more robust approach would be using signal masking to block signals, as done in this PR: #616

However, we might not need to handle exit signals in MSGQSubSocket::receive() at all. We could instead delegate exit signal handling to the caller, following the approach in commaai/openpilot#32367 (closed by bot), where signal handling in params was removed entirely.

update:

Reopened the PR to move blocking read functionality to Cython: commaai/openpilot#34407