lix/src/libutil
Robert Hensing c3b942e0fc Don't hold interruptCallbacks lock during interrupt handling
This changes the representation of the interrupt callback list to
be safe to use during interrupt handling.

Holding a lock while executing arbitrary functions is something to
avoid in general, because of the risk of deadlock.

Such a deadlock occurs in https://github.com/NixOS/nix/issues/3294
where ~CurlDownloader tries to deregister its interrupt callback.

This happens during what seems to be a triggerInterrupt() by the
daemon connection's MonitorFdHup thread. This bit I can not confirm
based on the stack trace though; it's based on reading the code,
so no absolute certainty, but a smoking gun nonetheless.
2022-02-06 13:53:28 +01:00
..
tests
abstract-setting-to-json.hh
ansicolor.hh
archive.cc
archive.hh
args.cc
args.hh
callback.hh
closure.hh
comparator.hh
compression.cc
compression.hh
compute-levels.cc
compute-levels.hh
config.cc
config.hh
error.cc
error.hh
experimental-features.cc
experimental-features.hh
finally.hh
fmt.cc
fmt.hh
hash.cc
hash.hh
json.cc
json.hh
local.mk
logging.cc
logging.hh
lru-cache.hh
monitor-fd.hh
pool.hh
ref.hh
serialise.cc
serialise.hh
split.hh
sync.hh
tarfile.cc
tarfile.hh
thread-pool.cc
thread-pool.hh
topo-sort.hh
types.hh
url-parts.hh
url.cc
url.hh
util.cc Don't hold interruptCallbacks lock during interrupt handling 2022-02-06 13:53:28 +01:00
util.hh
xml-writer.cc
xml-writer.hh