WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-cim

RE: [Xen-cim] Emailing: libxen.diff

To: "Ewan Mellor" <ewan@xxxxxxxxxxxxx>
Subject: RE: [Xen-cim] Emailing: libxen.diff
From: "Subrahmanian, Raj" <raj.subrahmanian@xxxxxxxxxx>
Date: Sun, 24 Dec 2006 02:20:50 -0500
Cc: xen-cim@xxxxxxxxxxxxxxxxxxx, Jim Fehlig <jfehlig@xxxxxxxxxx>
Delivery-date: Sat, 23 Dec 2006 23:21:06 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20061223101257.GB21934@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-cim-request@lists.xensource.com?subject=help>
List-id: xen-cim mailing list <xen-cim.lists.xensource.com>
List-post: <mailto:xen-cim@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-cim>, <mailto:xen-cim-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-cim>, <mailto:xen-cim-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Accmeu2Pb+w/iN7YTfOmkdd2+9VbgwAea2Gg
Thread-topic: [Xen-cim] Emailing: libxen.diff
Ewan,
It looks like if we can just do these inside _init and _fini (which are
functions called when the library is loaded and unloaded respectively),
we won't need to wory about MT-safeness. The OS won't unload the shared
library till everyone who's linked to it has unloaded.
Was there any specific reason why there were specific xen_init and
xen_fini calls created?

Raj

> -----Original Message-----
> From: Ewan Mellor [mailto:ewan@xxxxxxxxxxxxx] 
> Sent: Saturday, December 23, 2006 5:13 AM
> To: Subrahmanian, Raj
> Cc: xen-cim@xxxxxxxxxxxxxxxxxxx; Jim Fehlig
> Subject: Re: [Xen-cim] Emailing: libxen.diff
> 
> On Fri, Dec 22, 2006 at 10:00:49PM -0500, Subrahmanian, Raj wrote:
> 
> > This will MT-safe the xen_init and xen_fini calls, so that 
> we can do 
> > it once for each provider than for each call.
> 
> I don't think that this belongs in libxen, as that library 
> shouldn't add a dependency on libpthread unconditionally.  
> Can't you do this inside the provider?
> 
> Ewan.
> 
> > Raj
> >  <<libxen.diff>>
> 
> > diff -r 8348f40ba2b7 tools/libxen/Makefile
> > --- a/tools/libxen/Makefile Thu Dec 21 14:49:19 2006 +0000
> > +++ b/tools/libxen/Makefile Fri Dec 22 17:32:26 2006 -0500
> > @@ -27,7 +27,8 @@ CFLAGS = -Iinclude                     \
> >           -W -Wall -Wmissing-prototypes -Werror -std=c99 -O2 -fPIC
> >  
> >  LDFLAGS = $(shell xml2-config --libs) \
 > -          $(shell curl-config --libs)
> > +          $(shell curl-config --libs) \
> > +     -lpthread
> >  
> >  LIBXENAPI_HDRS = $(wildcard include/*.h)  LIBXENAPI_OBJS = 
> $(patsubst 
> > %.c, %.o, $(wildcard src/*.c)) diff -r 8348f40ba2b7 
> > tools/libxen/include/xen_common.h
> > --- a/tools/libxen/include/xen_common.h     Thu Dec 21 
> 14:49:19 2006 +0000
> > +++ b/tools/libxen/include/xen_common.h     Fri Dec 22 
> 17:32:26 2006 -0500
> > @@ -24,13 +24,13 @@
> >  #include <stddef.h>
> >  #include <stdint.h>
> >  #include <time.h>
> > -
> > +// The init and the fini really need to happen only once. 
> > +// The mutex will take care of that
> > +#include <pthread.h>
> >  #include "xen_host_decl.h"
> > -
> >  
> >  typedef bool (*xen_result_func)(const void *data, size_t len,
> >                                  void *result_handle);
> > -
> >  
> >  /**
> >   * len does not include a terminating \0.
> > diff -r 8348f40ba2b7 tools/libxen/src/xen_common.c
> > --- a/tools/libxen/src/xen_common.c Thu Dec 21 14:49:19 2006 +0000
> > +++ b/tools/libxen/src/xen_common.c Fri Dec 22 17:32:26 2006 -0500
> > @@ -43,6 +43,8 @@
> >  #define PERMISSIVE 1
> >  
> >  
> > +static pthread_mutex_t mutexUserCount=PTHREAD_MUTEX_INITIALIZER;
> > +static unsigned UserCount=0;
> >  static xmlXPathCompExprPtr responsePath = NULL;  static 
> > xmlXPathCompExprPtr faultPath = NULL;
> >  
> > @@ -111,23 +113,35 @@ void
> >  void
> >  xen_init(void)
> >  {
> > -    responsePath =
> > -        xmlXPathCompile(
> > -            BAD_CAST(
> > -                
> "/methodResponse/params/param/value/struct/member/value"));
> > -    faultPath =
> > -        xmlXPathCompile(
> > -            
> BAD_CAST("/methodResponse/fault/value/struct/member/value"));
> > +    pthread_mutex_lock(&mutexUserCount);
> > +    if (UserCount==0)
> > +    {
> > +           responsePath =
> > +           xmlXPathCompile(
> > +                   BAD_CAST(
> > +                   
> "/methodResponse/params/param/value/struct/member/value"));
> > +           faultPath =
> > +           xmlXPathCompile(
> > +                   
> BAD_CAST("/methodResponse/fault/value/struct/member/value"));
> > +    }
> > +    UserCount++;
> > +    pthread_mutex_unlock(&mutexUserCount);
> >  }
> >  
> >  
> >  void
> >  xen_fini(void)
> >  {
> > -    xmlXPathFreeCompExpr(responsePath);
> > -    xmlXPathFreeCompExpr(faultPath);
> > -    responsePath = NULL;
> > -    faultPath = NULL;
> > +    pthread_mutex_lock(&mutexUserCount);
> > +    UserCount--;
> > +    if (UserCount==0)
> > +    {
> > +        xmlXPathFreeCompExpr(responsePath);
> > +        xmlXPathFreeCompExpr(faultPath);
> > +        responsePath = NULL;
> > +        faultPath = NULL;
> > +    }
> > +    pthread_mutex_unlock(&mutexUserCount);
> >  }
> 
> > _______________________________________________
> > Xen-cim mailing list
> > Xen-cim@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-cim
> 
> 

_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim

<Prev in Thread] Current Thread [Next in Thread>