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–38 of 38 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]