IdeaWell

Project ideas from Hacker News discussions.

Is it safe to call print in a Python signal handler?

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Theme 1 – Signal handling is notoriously tricky, especially with threads or event loops
- IgorPartola: “What’s really fun is mixing signal handling and threads, especially on Linux. There is a simple way to do it and about a thousand ways that include at least one gotcha.”
- Uptrenda: “And when you combine it with event loops and multiple OSes + python versions it gets even more difficult.”
- jrumbut: “If you put a print statement in the handler, you can get this result.”

Theme 2 – POSIX signals are fundamentally unsafe; alternatives like signalfd or self‑pipe are needed
- nine_k: “POSIX signals are broken by design, alas: https://lwn.net/Articles/414618/ Python or not, almost nothing is safe inside a signal handler.”
- inigyou: “The ones related to application logic must only be handled with signalfd if you want any semblance of reliability.”
- charcircuit: “Signals should just come in via a new thread and it would solve all the complexity around them.”
- inigyou: “They should come in via signalfd unless they're the moral equivalent of a non‑maskable interrupt.”

Theme 3 – Python’s signal handling works via a flag‑based deferral, which changes the safety picture but doesn’t eliminate problems
- knome: “the first line of the article points out that python isn't run in the POSIX C handler. that just sets a flag for the interpreter to act on. the python issue is an unsafe re‑entrant handling strategy in the interpreter.”
- megagpt3: “He 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?”

🚀 Project Ideas

Generating project ideas…

SigSafePy

Summary

  • A Python library that provides thread‑safe, asyncio‑compatible signal handling using signalfd (Linux) or a self‑pipe fallback, exposing simple context managers and decorators.
  • Core value: lets developers register signal handlers without worrying about re‑entrancy, unsafe C‑level calls, or mixing with event loops.

Details

Key Value
Target Audience Python developers building servers, CLI tools, or async applications that need reliable shutdown / signal handling
Core Feature Safe signal registration via with SigSafe(signal.SIGTERM): or @sigsafe_handler that internally uses signalfd/self‑pipe and delivers signals to asyncio queues or threads
Tech Stack Python 3.11+, C extension for signalfd, optional fallback to selector + pipe, pytest for testing
Difficulty Medium
Monetization Hobby

Notes

  • HN commenters expressed pain with mixing signals, threads, and event loops (Uptrenda: "If someone built a (good) lib for this it would probably be quite popular").
  • Provides a single, well‑tested abstraction that works across Python versions and platforms, reducing boilerplate and the risk of unsafe handler code.

SignalGuard

Summary

  • A static analysis/linter tool that scans Python (and optionally C) source code for patterns that are unsafe inside signal handlers (e.g., calling print, allocating memory, acquiring locks).
  • Core value: catches potential signal‑handler bugs at development time, preventing hard‑to‑reproduce crashes in production.

Details

Key Value
Target Audience Software engineers maintaining multithreaded or event‑driven codebases, especially those using signal handling for graceful shutdown
Core Feature Rule‑based detection (via AST for Python, Clang‑based for C) of non‑async‑signal‑safe calls, with quick‑fix suggestions and severity ratings
Tech Stack Python (ast, tokenize) for Python analysis; libclang bindings for C/C++; distributed as a pip package and pre‑commit hook
Difficulty Low
Monetization Hobby

Notes

  • Commenters noted the danger of seemingly innocuous code (jrumbut: "If you put a print statement in the handler, you can get this result"); SignalGuard would flag such prints automatically.
  • Enables teams to enforce a "signal‑handler safe" coding standard, fostering discussion about best practices and reducing production incidents.

Signalfd Bridge

Summary

  • A lightweight, portable C library that provides a signalfd‑like file descriptor interface on Linux, macOS, and Windows (using self‑pipe, kqueue, or eventfd under the hood).
  • Core value: gives language bindings (C, Rust, Go, Python) a uniform way to receive signals as readable file descriptors, simplifying integration with event loops and avoiding handler re‑entrancy issues.

Details

Key Value
Target Audience Systems programmers, library authors, and application developers who need reliable signal handling across OSes
Core Feature Cross‑platform signalfd_create(signum_set) returning an fd that can be polled/selected; includes bindings and example integrations with libuv, asyncio, Tokio
Tech Stack C11 core, conditional compilation for Linux (signalfd), macOS (kqueue), Windows (WSAPipe/CompletionPort); bindings generated via cffi, pyo3, rust-bindgen
Difficulty High
Monetization Hobby

Notes

  • Several HN users advocated moving signals to a separate thread or file descriptor (charcircuit: "Signals should just come in via a new thread" and inigyou: "They should come in via signalfd unless they're the moral equivalent of a non-maskable interrupt").
  • Signalfd Bridge directly satisfies that desire, offering a battle‑tested, easy‑to‑use abstraction that would likely generate discussion and adoption in the systems‑programming community.

Read Later