Em qui., 14 de mai. de 2020 às 07:42, Phil Endecott via Boost < boost@lists.boost.org> escreveu:
* The system could be made more robust by blocking signals while a mutex is locked. This doesn't help with crashes, e.g. segfaults, but it would help with ctrl-C.
I don't think this is a good idea. Signals are a property of the application and libraries rarely should touch signals silently. Blocking signals (instead handling them) is better, but it shouldn't happen across the return of some function without a good excuse. I'm less clear about what happens to condition variables, but it
does seem that perhaps terminating a process while it is waiting on a condition will cause other processes to deadlock. Perhaps the wait conceptually returns and the mutex is re-locked during termination.
These are all tricky questions. POSIX gets away by deferring decision to the user and it does work. The challenge here is adapting the problem to the vocabulary of C++ objects model. If we do proceed with your idea about read/write locks, the PTHREAD_MUTEX_ROBUST solution could be mapped into the lock object. unique_lock -> we can't assume anything, then we use this most broad assumption: a write lock and no recovery mechanisms in using code unique_read_lock -> read lock unique_robust_lock -> stores extra data about the lock state that the user can query after lock is acquired. This should be enough to map PTHREAD_MUTEX_ROBUST behaviour and make it work with condition variables. unique_robust_lock lk{mtx}; for (;;) { if (!lk.consistent()) { // mutex acquired // but in inconsistent state // user has to deal with it } if (predicate) break; cond.wait(lk); } What do you think? -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/