"unfairness" of juju/mutex

[Andrew Wilkins]

On Thu, Nov 17, 2016 at 10:07 PM roger peppe <roger.peppe at canonical.com>
wrote:

> On 17 November 2016 at 12:12, Stuart Bishop <stuart.bishop at canonical.com>
> wrote:
> > On 17 November 2016 at 02:34, roger peppe <roger.peppe at canonical.com>
> wrote:
> >>
> >> +1 to using blocking flock. Polling is a bad idea with a heavily
> contended
> >> lock.
> >>
> >> FWIW I still think that mutexing all unit hooks is a bad idea
> >> that's really only there to paper over the problem that apt-get
> >> doesn't work well concurrently.
> >
> >
> > apt is just the one you commonly trip over. If there was no mutex, then
> > charms would need to do their own locking for every single resource they
> > need to access that might potentially also be accessed by a subordinate
> (now
> > or in the future), and hope subordinates also use the lock. So I think
> > mutexing unit hooks on the same machine is a fantastic idea :) Just
> > something innocuous like 'adduser' can collide with a subordinate
> wanting to
> > stick a config file in that user's home directory.
>
> Surely a hook mutex primitve (e.g. "mutex adduser ...") would have been
> more appropriate than the sledgehammer approach of mutexing everything
> all the time? Sometimes I might want a hook to run for a long time
> (or it might unfortunately block on the network) and turning off all
> subordinate hooks while that happens doesn't seem right to me.
>
> Anyway, I appreciate that it's too late now. We can't change this
> assumption
> because it'll break all the charms that rely on it.
>

We could support the opposite, though: explicitly releasing the lock while
executing a command. That won't break anything.

  cheers,
>     rog.
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20161117/2552eba3/attachment.html>