CFFI耦合C库遇exit代码终止问题：trivial-signal兼容性及方案咨询

Great question! Let’s break this down step by step based on your scenario with CFFI and that pesky C library exiting unexpectedly.

1. Does trivial-signal support Windows? #

Short answer: No, not meaningfully. The trivial-signal library is built around Unix-like signal mechanisms (think SIGTERM, SIGINT) which don’t translate cleanly to Windows’ entirely different process termination and error handling model. Most of its core functionality won’t work as intended on Windows, so you’ll need alternative approaches if you’re targeting that platform.

2. Other ways to prevent your Lisp program from terminating #

If modifying the original C library isn’t an option, here are practical workarounds:

• Run C library calls in a child process: Use your Lisp implementation’s process management tools (like uiop:run-program in many implementations) to spawn a separate child process for executing the C library functions. If the child process exits, your main Lisp program can capture the exit code and handle it gracefully without terminating. This works cross-platform, including Windows.
• Build a C wrapper layer: Create a small intermediate C library that links against your target C library, then redefine exit (or any error-exiting functions) to return an error code instead of killing the process. Use CFFI to call this wrapper instead of the original library—your Lisp code can then check return codes and handle errors natively.
• Lisp implementation-specific hooks: Some Common Lisp implementations (like SBCL on Unix) let you override process termination signals, but this is highly platform-dependent and not portable. For Windows, you’d need to integrate with Win32 API functions like SetUnhandledExceptionFilter via CFFI, which requires low-level work but is doable.

3. Is replacing exit with a Lisp callback that throws exceptions feasible? #

Absolutely—this is one of the cleanest solutions if you can modify or wrap the C library. Here’s how to pull it off:

• Define a Lisp callback using cffi:defcallback that accepts an exit code and throws a Lisp condition (error):

  (cffi:defcallback error-handler :void ((code :int))
    (error "C library attempted to exit with code ~a" code))
  

• Modify or wrap the C library: Either edit the original C code to call your callback instead of exit, or build a wrapper that intercepts exit calls. For example, in your wrapper C code:

  // Declare the callback type
  typedef void (*error_handler_t)(int);
  error_handler_t lisp_error_handler;
  
  // Override exit to trigger the Lisp callback
  void exit(int code) {
      if (lisp_error_handler != NULL) {
          lisp_error_handler(code);
      }
      // Optional: Fall back to original exit if no callback is set
      // original_exit(code);
  }
  
  // Function to register the callback from Lisp
  void register_error_handler(error_handler_t handler) {
      lisp_error_handler = handler;
  }
  

• Register the callback from Lisp: Use CFFI to link your callback to the C wrapper:

  (cffi:foreign-funcall "register_error_handler" :pointer (cffi:callback error-handler) :void)
  

A couple of key notes:

• Make sure the callback is called in a thread-safe context. Some C libraries might invoke exit from signal handlers or multi-threaded code, which could conflict with Lisp’s runtime—keep the callback logic simple (just throw the error) to avoid issues.
• If you can’t modify the original C library, use dynamic symbol interposition (Unix: LD_PRELOAD, Windows: API hooking) to redirect exit calls to your wrapper. This is more advanced but entirely possible.

内容的提问来源于stack exchange，提问作者Dimitris