On Wed, Apr 15, 2020 at 03:58:55PM +0100, Daniel P. Berrangé wrote:
> On Wed, Apr 15, 2020 at 04:11:30PM +0200, Pavel Mores wrote:
> > On Wed, Apr 15, 2020 at 01:55:34PM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Apr 14, 2020 at 05:24:50PM +0200, Pavel Mores wrote:
> > > > On Fri, Apr 10, 2020 at 03:54:28PM +0200, Rafael Fonseca wrote:
> > > > > Signed-off-by: Rafael Fonseca <[email protected]>
> > > > > ---
> > > > > src/admin/admin_server_dispatch.c | 13 ++++---------
> > > > > 1 file changed, 4 insertions(+), 9 deletions(-)
> > > > >
> > > > > diff --git a/src/admin/admin_server_dispatch.c
> > > > > b/src/admin/admin_server_dispatch.c
> > > > > index b3da577995..2515528779 100644
> > > > > --- a/src/admin/admin_server_dispatch.c
> > > > > +++ b/src/admin/admin_server_dispatch.c
> > > > > @@ -45,7 +45,7 @@ typedef daemonAdmClientPrivate
> > > > > *daemonAdmClientPrivatePtr;
> > > > > /* Separate private data for admin connection */
> > > > > struct daemonAdmClientPrivate {
> > > > > /* Just a placeholder, not that there is anything to be locked */
> > > > > - virMutex lock;
> > > > > + GMutex lock;
> > > > >
> > > > > virNetDaemonPtr dmn;
> > > > > };
> > > > > @@ -55,7 +55,7 @@ remoteAdmClientFree(void *data)
> > > > > {
> > > > > struct daemonAdmClientPrivate *priv = data;
> > > > >
> > > > > - virMutexDestroy(&priv->lock);
> > > > > + g_mutex_clear(&priv->lock);
> > > > > virObjectUnref(priv->dmn);
> > > > > VIR_FREE(priv);
> > > > > }
> > > > > @@ -91,11 +91,7 @@ remoteAdmClientNew(virNetServerClientPtr client
> > > > > G_GNUC_UNUSED,
> > > > > if (VIR_ALLOC(priv) < 0)
> > > > > return NULL;
> > > > >
> > > > > - if (virMutexInit(&priv->lock) < 0) {
> > > > > - VIR_FREE(priv);
> > > > > - virReportSystemError(errno, "%s", _("unable to init mutex"));
> > > > > - return NULL;
> > > > > - }
> > > > > + g_mutex_init(&priv->lock);
> > > > >
> > > > > /*
> > > > > * We don't necessarily need to ref this object right now as
> > > > > there
> > > > > @@ -167,9 +163,9 @@ adminDispatchConnectOpen(virNetServerPtr server
> > > > > G_GNUC_UNUSED,
> > > > > struct daemonAdmClientPrivate *priv =
> > > > > virNetServerClientGetPrivateData(client);
> > > > > int ret = -1;
> > > > > + g_autoptr(GMutexLocker) locker = g_mutex_locker_new(&priv->lock);
> > > > >
> > > > > VIR_DEBUG("priv=%p dmn=%p", priv, priv->dmn);
> > > > > - virMutexLock(&priv->lock);
> > > > >
> > > > > flags = args->flags;
> > > > > virCheckFlagsGoto(0, cleanup);
> > > > > @@ -178,7 +174,6 @@ adminDispatchConnectOpen(virNetServerPtr server
> > > > > G_GNUC_UNUSED,
> > > > > cleanup:
> > > > > if (ret < 0)
> > > > > virNetMessageSaveError(rerr);
> > > > > - virMutexUnlock(&priv->lock);
> > > > > return ret;
> > > > > }
> > > > >
> > > > > --
> > > > > 2.25.2
> > > >
> > > > I was wondering why virMutexInit() returns a value whereas
> > > > g_mutex_init() does
> > > > not, to make sure there weren't any additional adjustments necessary,
> > > > but it's
> > > > probably OK.
> > > >
> > > > I mean, it does feel slightly dubious as virMutexInit() fails if
> > > > pthread_mutex_init() fails which can happen under a bunch of seemingly
> > > > fairly
> > > > realistic scenarios. I assume g_mutex_init() ultimately calls
> > > > pthread_mutex_init() as well so these scenarios should still apply.
> > > >
> > > > However, this seems ultimately a problem of glib API designers to
> > > > decide how
> > > > realistic the scenarios are (at least some of them seem to be related
> > > > to memory
> > > > allocation which glib solves by aborting) and whether to report them to
> > > > their
> > > > users, and they made the decision that they made, hopefully for good
> > > > reasons.
> > >
> > > Honestly, none of the reasons mutex init can fail are especially
> > > interesting to callers. There's essentially nothing useful callers
> > > can do when a mutex init fails, as its symptomatic of much bigger
> > > problems. Thus I think abort'ing is a reasonable approach. Likewise
> > > for lock/unlock.
> >
> > Yes, agreed. At the risk of going off-topic, what makes me wonder is that
> > phtread_mutex_init() POSIX manual page lists also EPERM among the reasons
> > why
> > the call might fail. I've never heard of that, let alone encountered it,
> > and
> > it might not actually be implemented by OS's in practice. However if EPERM
> > can
> > happen, then I guess that could be worth reporting to the user.
>
> Any OS that is crazy enough to report EPERM for initializing mutex is not
> an OS I wish to support :-)
That seems fair enough. :-)
pvl
