Closed avsm closed 10 years ago
Actually it is already the case: Scheduler.go ()
does manage SIGPIPE
. In the documentation:
[go ()] calls [handle_signal Sys.sigpipe], which causes the SIGPIPE signal to be
ignored. Low-level syscalls (e.g. write) still raise EPIPE.
Async installs a signal handler instead of setting the signal disposition to ignore, but the result is the same: write
will fail with EPIPE
instead of the process being terminated. That's what is shown in the backtrace.
Got it; I just wasn't ignoring handler errors correctly; now fixed and confirmed that all's working. thanks!
Right now SIGPIPE exceptions can leak out and kill the whole server process in Cohttp_async. There's no real reason to not ignore SIGPIPE these days, since the next read/write will result in an error in the return code anyway.
Can it be blocked globally when linking Async?