Opened 15 years ago

Closed 14 years ago

Last modified 12 years ago

#19935 closed defect (fixed)

need per-port locking, not just per-target

Reported by: vinc17@… Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts 1.9.2
Component: base Version: 1.7.1
Keywords: lock Cc: ryandesign (Ryan Carsten Schmidt)
Port:

Description

I've tried to upgrade two ports A and B at the same time with: 

$ sudo port -v upgrade A
$ sudo port -v upgrade B

in two different shell sessions. Port B depends on A. As expected, the upgrade of port B waited for a lock while the new version of port A was being built. But the following problem occurred: both occurrences of the port command tried to deactivate port A at the same time, so that one of the deactivate operations failed.

Change History (4)

comment:1 Changed 15 years ago by blb@…

Keywords: lock added
Milestone: → MacPorts Future

comment:2 Changed 15 years ago by jmroot (Joshua Root)

Summary: incorrect locking policy with deactivate → need per-port locking, not just per-target

comment:3 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

Has duplicate #24858.

comment:4 Changed 14 years ago by jmroot (Joshua Root)

Milestone: MacPorts Future → MacPorts 1.9.2
Resolution: → fixed
Status: new → closed

Should be OK as of r70174 / r70175. I went for the simpler approach of having one exclusive lock for all actions that modify the registry.

Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)
Note: See TracTickets for help on using tickets.