apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: cvs commit: apr CHANGES libapr.dsp apr.dsp
Date Tue, 19 Feb 2002 22:16:07 GMT
From: "Bill Stoddard" <bill@wstoddard.com>
Sent: Tuesday, February 19, 2002 3:31 PM


> I considered this but in the interest of keeping the code squeaky clean, decided
> otherwise. I don't object to your solution, though others might. I can go either way...

And I had considered the apr_global_mutex_t and apr_proc_mutex_t pointers, and the
advantage of keeping them unrelated [but figured 95% of possible mistakes would be
picked up on another platform.]  I could fall either way as well... We can wait and
see if others have any comments.

Bill

> >
> >  /*   Function definitions */
> > @@ -156,6 +158,24 @@
> >   * @return apr_pool_t the pool
> >   */
> >  APR_POOL_DECLARE_ACCESSOR(global_mutex);
> > +
> > +#else
> > +
> > +/* Some platforms [e.g. Win32] have cross process locks that are truly
> > + * global locks, since there isn't the concept of cross-process locks
> > + * Define these platforms in terms of an apr_proc_mutex_t.
> > + */
> > +
> > +#define apr_global_mutex_t          apr_proc_mutex_t
> > +#define apr_global_mutex_create     apr_proc_mutex_create
> > +#define apr_global_mutex_child_init apr_proc_mutex_child_init
> > +#define apr_global_mutex_lock       apr_proc_mutex_lock
> > +#define apr_global_mutex_trylock    apr_proc_mutex_trylock
> > +#define apr_global_mutex_unlock     apr_proc_mutex_unlock
> > +#define apr_global_mutex_destroy    apr_proc_mutex_destroy
> > +#define apr_global_mutex_pool_get   apr_proc_mutex_pool_get
> > +
> > +#endif
> >
> >  #ifdef __cplusplus
> >  }
> >
> >
> 
> 


Mime
View raw message