Locking (was: 1.9.2)

[Joshua Root]

On 2010-8-6 11:21 , Rainer Müller wrote:
> On 2010-08-05 16:25 , Joshua Root wrote:
>> On 2010-8-5 23:24 , Rainer Müller wrote:
>>> The problem with activate/deactivate was introduced by the fact that
>>> activation/deactivation is now being run from the registry Portfile
>>> making the statefile lock ineffective for another instance working on
>>> the Portfile in the tree.
>>
>> That may have made the problem more noticeable in some situations, but
>> it didn't cause it.
> 
> Hm, in which other situation would macports first check the current
> state and act later?

Any action on pseudoports like installed, outdated, inactive. Computing
dependencies when installing a port (makes a list of which ones are not
installed and active and then activates them all later).

> And in which case can such a thing happen while changing requested
> ports, which you added to the actions requiring locking?

Doing anything involving the requested, unrequested or leaves pseudoports.

>>> I don't think the solution for this is a general lock so only one port
>>> instance can run.
>>
>> It's the only simple, correct solution that I can see.
> 
> Okay, if this is what we are going to use now it's implementation is not
> correct at the moment. It is now locking in the port command line client
> and is likely to cause the same problem again when using another client
> in parallel, e.g. MacPorts Framework for GUI. So this should at least be
> moved to the macports package instead as it is clearly not a issue with
> the command line client only.

It can't go in macports1.0, as you have to lock before evaluating
pseudoports. Yes, the framework needs to lock as well.

- Josh