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-27 14:25:27

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:
>> 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
>