Marijn Suijten

~This must be the `Drop` that is not synchronized. `ReleaseMutex(self.lock)` releases the lock without ever clearing the atomic in `static LOCK`. Subsequent calls to `init()` (after a prior allocated `Init`...

I get a unique handle value for every call to `CreateMutexA` with the same shared mutex name. Closing that handle does not seem to affect the shared mutex in any...

@alexcrichton I'm hesitant to accept `WAIT_ABANDONED` as "success" for aforementioned reasons, who knows what state `dbghelp` is in and how much that might break. We definitely have to perform some...

@repi Unfortunately we have not been able to repro this anymore bar the threading example above. Maybe there are short-living and panicking threads spawned after all? This seems to be...

I count that as not repro'ing it anymore! For us it was probably recording a callstack right as a panic was being handled, which did not end up releasing before...

@kamulos Fwiw `cargo-deny` has a special [`license.clarify`](https://embarkstudios.github.io/cargo-deny/checks/licenses/cfg.html#the-clarify-field-optional) section. This includes a checksum of the license file so that the manual clarification/checking only remains valid for as long as that file...

@carlsmedstad That's interesting, I can't reproduce that here but it could be ZSH being smart about killing subprocesses/jobs. Manually sending a SIGINT shows the issue. Are you sure all signals...

@carlsmedstad That's unfortunate; how about `pkill $(jobs -p)`? EDIT: Though that likely doesn't work either, given that only the `&` shell is a job - all subprocesses will live on...

@carlsmedstad Sources mentioned a similar issue with `kill 0` killing the entire process tree rather than only the processes below it (and itself?). According to those outputs it is indeed...

@carlsmedstad I completely agree. As a matter of fact the first thing that was looked up when starting this modification was a `poll`/`select`/`epoll` in bash, to have a single thread...