summaryrefslogtreecommitdiff
path: root/unpack
diff options
context:
space:
mode:
authorDavid Oberhollenzer <david.oberhollenzer@sigma-star.at>2019-12-05 12:15:21 +0100
committerDavid Oberhollenzer <david.oberhollenzer@sigma-star.at>2019-12-05 12:32:00 +0100
commite17da4c1150b1f8be9071c7403163ea6fb518c6e (patch)
tree578746027e656a7d86f0eb81aa4b42a3d0d2ba33 /unpack
parent199c35e4c9cfd10d070392d58625e86b2f8f4c19 (diff)
Fix pthread data writer interfering with signal handling
If a signal is sent to a process, the POSIX spec says that ANY thread could be picked ARBITRARILY to handle the signal. In our case this could be one of the internal worker threads. The problem here is that an unsuspecting user of the library might suddenly have their signal handler run in parallel to their main thread and run into weird concurrency issues, because they didn't expect that to happen. In fact, the libsquashfs API tries to be transparent about whether or not it uses a thread pool internally and does everything other than number crunching (e.g. I/O that may happen through user supplied callbacks) in the same thread as the one that submitts the blocks. Unfortunately, pthread doesn't have a way to set a signal mask for the new thread and setting it inside the thread is racy (i.e. a signal might be delivered before the worker thread sets the mask). The only portable and non-racy way to do this, is to disable all signals in the calling thread that sets up the data writer, create the threads (which will inherit the mask) and then resetore the previous signal mask, hoping for the best. The downside to this is that signals may be lost in that short time. Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Diffstat (limited to 'unpack')
0 files changed, 0 insertions, 0 deletions