On Thu, Nov 17, 2016 at 10:07 PM roger peppe <roger.pe...@canonical.com> wrote:
> On 17 November 2016 at 12:12, Stuart Bishop <stuart.bis...@canonical.com> > wrote: > > On 17 November 2016 at 02:34, roger peppe <roger.pe...@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@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
