Ivan Petkov

@Firstyear > https://github.com/tokio-rs/tokio/blob/master/tokio/src/runtime/driver.rs#L10 This is where the driver is registered, but signal handlers are lazily registered here: https://github.com/tokio-rs/tokio/blob/master/tokio/src/runtime/driver.rs#L10 It seems like something in the application is registering a signal one...

> I wrote a little test program and was able to confirm that the signal handler for SIGCHLD is installed eagerly when the process and signal features are enabled, even...

> Because another part of my application does require signal handling. Wouldn't this part of the application turn signal handling back on in the runtime and bring you back to...

> the real issue is that Tokio installing a SIGCHLD handler at all may cause whatever else in the process is doing so to lose notifications. I'm curious to understand...

> In my case the GLib code happens to run after tokio, and the GLib code is making no attempt to preserve the previous handler. The Unix signal APIs are...

I think one way to resolve the tension of issues with an async-sync-async sandwich, without forcing callers to use an async API, is to change the `force_flush` APIs to take...

Hi @TommyCpp thanks for the quick response! > It actually does, if you look at singal, it employes a zero side channel and block on it until it receives the...

Hmm interesting, there's two parts of the code which come to mind: 1. Parsing the git dependency in Cargo.lock (though nothing about the code immediately jumps out as the culprit):...

It's worth noting that `nix build --keep-going` will continue trying to build _unrelated_ derivations; if a derivation's build script fails, Nix won't install anything (and any other derivations which depend...

Hi @Velnbur if you run `wasm-pack` via `strace` what does it show? I wonder if `wasm-pack` is trying to write files in a source directory somewhere (instead of some other...