Earlier quoted context omitted.
They should come in via signalfd unless they're the moral equivalent of a non-maskable interrupt.
And for people who want to use something other than Linux?
BSD kqueue, Solaris ports.
Is it safe to call print in a Python signal handler?
31–40 of 40 posts
Re: Is it safe to call print in a Python signal handler?
#32Earlier quoted context omitted.
It may help if you think of them as interrupts and not something that comes in your message queue.
No, I understand that. I just find it deeply ironic that when an interrupt/signal arrives, pretty much the only thing you can do to handle it, is to raise some flag, then leave the handler and continue doing whatever you were doing in a message loop. Like, why even bother with supporting function callbacks in sigaction() etc? Just have each thread have a chunk of volatile memory where the kernel writes info about the…
> No, I understand that. I just find it deeply ironic that when an interrupt/signal arrives, pretty much the only thing you can do to handle it, is to raise some flag, then leave the handler and continue doing whatever you were doing in a message loop.
That's how most hardware interrupts would also work.
Re: Is it safe to call print in a Python signal handler?
#33Earlier quoted context omitted.
Exactly, the only safe thing to do in a signal is set a variable for other code to react on, also they completely mess up in multi-threaded code.
That is exactly what I do: set an stomic variable and do yhings outside of the handler.
And that is pretty much what Python does for you, the Python-level signal handlers are not C signal handlers. Python sets a C signal handler to set an interpreter variable then exit, then it calls the Python level signal handler on the main thread (and on the main thread only, which can be a concern in sone cases).
Re: Is it safe to call print in a Python signal handler?
#34[flagged]
Re: Is it safe to call print in a Python signal handler?
#35Earlier quoted context omitted.
They should come in via signalfd unless they're the moral equivalent of a non-maskable interrupt.
That is also good, but requires apps be rewritten to read from signalfd. With the separate thread approach you can get away without having to rewrite programs.
Incorrect. With the separate thread approach you added a lot of new race conditions.
Re: Is it safe to call print in a Python signal handler?
#36He considers it safe if it's unlikely to crash? That's also true in C. Calling printf in a C signal handler is likely to work. So why does he consider it important in C but "not a practical consideration" in Python? It's more likely to crash in Python than in C because the signal handler takes longer to execute.
The article mentions that the Python handler is run outside of the C handler context and so is not subject to the C safety restrictions. It will not crash since the interpreter only calls the Python handler when it is safe. It will however not protect against reentrancy issues in the Python handler. The C printf function is not async signal safe and is one of the examples in the manual: https://man7.org/linux/man-pag…
But it did crash. Did we read the same article? He shows the output it prints when it crashes.
Re: Is it safe to call print in a Python signal handler?
#37Earlier quoted context omitted.
That is also good, but requires apps be rewritten to read from signalfd. With the separate thread approach you can get away without having to rewrite programs.
Incorrect. With the separate thread approach you added a lot of new race conditions.
In practice I don't think there would be that many. You could even pause execution of the thread that would have gotten the signal to make it even safer.
Re: Is it safe to call print in a Python signal handler?
#38Earlier quoted context omitted.
No, I understand that. I just find it deeply ironic that when an interrupt/signal arrives, pretty much the only thing you can do to handle it, is to raise some flag, then leave the handler and continue doing whatever you were doing in a message loop. Like, why even bother with supporting function callbacks in sigaction() etc? Just have each thread have a chunk of volatile memory where the kernel writes info about the…
> No, I understand that. I just find it deeply ironic that when an interrupt/signal arrives, pretty much the only thing you can do to handle it, is to raise some flag, then leave the handler and continue doing whatever you were doing in a message loop. That's how most hardware interrupts would also work.
[deleted]
Re: Is it safe to call print in a Python signal handler?
#39Earlier quoted context omitted.
How would you fix signals and do you propose a complete set of patterns for safe concurrency? And so why is there limited scope for signal handlers? Should you use signal handlers with eBPF?
It's not really possible to make them safer without hurting performance. Signals break the C virtual machine guarantees (atomics, memory consistency, register consistency, etc), and the only way to re-establish them for edge cases like signals would be to cripple the rest of the program with extra checks (basically making ALL data volatile).
I guess that's why unix signals are not appropriate for concurrent message handling
Re: Is it safe to call print in a Python signal handler?
#40Earlier quoted context omitted.
No, I understand that. I just find it deeply ironic that when an interrupt/signal arrives, pretty much the only thing you can do to handle it, is to raise some flag, then leave the handler and continue doing whatever you were doing in a message loop. Like, why even bother with supporting function callbacks in sigaction() etc? Just have each thread have a chunk of volatile memory where the kernel writes info about the…
How would you fix signals and do you propose a complete set of patterns for safe concurrency? And so why is there limited scope for signal handlers? Should you use signal handlers with eBPF?
> How would you fix signals
Well, I'd probably just get rid of them entirely? For example, Windows functions just fine without them: SIGINT is emulated by the kernel doing essentially pthread_create(..., ®istered_ctrl_c_handler) — which neatly sidesteps the question of "what existing thread receives the signal" by answering "none of them" — SIGILL/SIGSEGV are handled with SEH because that's essentially what they are, the exceptions; SIGSTOP/SIGKILL are instead proper process-management "syscalls" SuspendProcess/TerminateProcess (seriously, why is what essentially are ioctls on a pidfd was bolted onto signals, it makes zero sense), and most of other asynchronous signals are just done via different channels.
Honestly, the most useful things about the signals is that they will interrupt your syscalls with EINTR so your code may have a chance to look around and notice things that happened while it was blocked inside the kernel.
> a complete set of patterns for safe concurrency?
Pfft, that's easy: synchronous rendezvous and message queues; alternatively, CSP. We've known this answer since the early 70s.