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:
Stefan Arentz escribió:
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 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