Opened 11 years ago

Closed 10 years ago

Last modified 8 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 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 11 years ago by blb@…

Keywords: lock added
Milestone: MacPorts Future

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

Summary: incorrect locking policy with deactivateneed per-port locking, not just per-target

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

Cc: ryandesign@… added

Has duplicate #24858.

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

Milestone: MacPorts FutureMacPorts 1.9.2
Resolution: fixed
Status: newclosed

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 8 years ago by ryandesign (Ryan Schmidt) (previous) (diff)
Note: See TracTickets for help on using tickets.