Hmm, I've been thinking about this a little bit more, and I've more and more started to like the idea (not for its beauty, but more for its practicality)... How about adding (as an option?) this kind of behaviour to the emulated mutexes in interprocess? The Posix mutexes I assume guarantee some kind of robustness, so that if a process crashes its locks are released. by adding the below behaviour we get reasonably close to that behaviour for the emulated mutexes. Cheers Lars Lars Hagström wrote:
One idea could be that when a process obtains the mutex it stores its pid in it. Another process can then - if it takes too long to take the lock - check if there exists such a pid and if not just forcibly take the lock itself. Of course this assumes that locks are never held for "a long time", and is quite easily considered a horrible solution... But it may well work in many situations.
Lars
Ion Gaztañaga wrote:
The problem is that when I kill or Control-C the consumer that the producer stops. I assume that this is because some lock is held by the consumer and the producer is waiting for it.
Is there a way to release these locks when the consumer is killed? Or a way to detect this, so that I can release them manually or so? Ufff... Signals are quite difficult to handle. You will have the same
Stefan Arentz escribió: problems with other process-wide resources, like files. I can't think about any reliable solution right now. We would need to add cancellation to process-shared mutexes and that does not seem easy. The only think I can think is handling the signal (but avoiding ending the process) and setting a global variable that is checked by other threads. You could only use timed functions send/receive functions that check that global variable. If the variable is set, an exit from process cleanly (exit from non-main threads). If you only use the main thread, throw an exception when the global variable is set. Not very clean, but I think it's the only way.
Regards,
Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users