registry lock

[Gustaf Neumann]

If there would be only readers, locking would not be necessary. When 
there is a single concurrent writer, locking is necessary, otherwise the 
reader could see inconsistent state (e.g. partial writes in the 
database, or in the file system, or in the interaction between these). 
Most systems use per default mutex-locks. Common optimizations 
distinguish between read-locks and write-locks, which allow multiple 
concurrent readers.

The Tcl thread package (part of tcl 8.6) supports rw-locks
-g

Am 18.11.15 um 13:01 schrieb Rainer Müller:
> On 2015-11-18 12:52, René J.V. Bertin wrote:
>> I agree that there should be a lock that prevents concurrent access
>> to the registry database, as that's something that appears likely to
>> lead to registry corruption. If the registry lock were to be set when
>> doing an (un)install or (de)activate, it'd be set very quickly when
>> issuing `port uninstall` or `port deactivate`, right?
> The problem is the time between the decision and when it is actually
> executed. The state should not change between that or you will run into
> problems.
>
> For example, see this report from before we had this locking:
> http://trac.macports.org/ticket/19935
>
> As I said, there is potential to allow certain operations with
> fine-grained locking, but it requires more planning to get this right.
> Just enforcing serialization of all actions that modify the registry is
> the easy solution that works in most cases.
>
> Rainer