Re: [Boost-users] Trying to get Boost.Interprocess going on OS X 10.5.1

From: Lars Hagström (lars_at_[hidden])
Date: 2007-11-26 09:27:14

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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users