You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Cliff Woolley <cl...@yahoo.com> on 2001/07/01 23:31:37 UTC
warnings with APR_USE_PROC_PTHREAD_SERIALIZE
Just a heads up on some warnings I'm getting on Solaris 2.6 where
APR_USE_PROC_PTHREAD_SERIALIZE is selected:
locks.c: In function `apr_os_lock_get':
locks.c:344: warning: assignment makes pointer from integer without a cast
locks.c: In function `apr_os_lock_put':
locks.c:365: warning: assignment makes integer from pointer without a cast
The problem is that (after macro substitution) my apr_os_lock_t looks like
this:
struct apr_os_lock_t {
pthread_mutex_t *crossproc;
pthread_mutex_t *intraproc;
};
And apr_os_lock_get/put assume that crossproc will be an int (as it is
with the other serialize methods).
I'd work on this, but it'd probably be easier for somebody who's spent
more time in the locking code than I have...
--Cliff
Re: warnings with APR_USE_PROC_PTHREAD_SERIALIZE
Posted by rb...@covalent.net.
Yeah, I realized #2 while running. I'll try to log into my solaris box
and fix this tonight.
Ryan
On Sun, 1 Jul 2001, Cliff Woolley wrote:
> On Sun, 1 Jul 2001 rbb@covalent.net wrote:
>
> > Does this solve the warnings?
> > If so, please apply.
>
> Two problems:
>
> (1) My system would never get into the elif because I have both SYSVSEM
> and FCNTL serialize:
>
> #define APR_USE_FLOCK_SERIALIZE 0
> #define APR_USE_SYSVSEM_SERIALIZE 0
> #define APR_USE_FCNTL_SERIALIZE 0
> #define APR_USE_PROC_PTHREAD_SERIALIZE 1
> #define APR_USE_PTHREAD_SERIALIZE 1
>
> #define APR_HAS_FLOCK_SERIALIZE 0
> #define APR_HAS_SYSVSEM_SERIALIZE 1
> #define APR_HAS_FCNTL_SERIALIZE 1
> #define APR_HAS_PROC_PTHREAD_SERIALIZE 1
> #define APR_HAS_RWLOCK_SERIALIZE 0
>
> #define APR_HAS_LOCK_CREATE_NP 1
>
> (2) pthread_interproc is actually used in crossproc.c
>
> Thanks,
> --Cliff
>
>
>
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: warnings with APR_USE_PROC_PTHREAD_SERIALIZE
Posted by Cliff Woolley <cl...@yahoo.com>.
On Sun, 1 Jul 2001 rbb@covalent.net wrote:
> Does this solve the warnings?
> If so, please apply.
Two problems:
(1) My system would never get into the elif because I have both SYSVSEM
and FCNTL serialize:
#define APR_USE_FLOCK_SERIALIZE 0
#define APR_USE_SYSVSEM_SERIALIZE 0
#define APR_USE_FCNTL_SERIALIZE 0
#define APR_USE_PROC_PTHREAD_SERIALIZE 1
#define APR_USE_PTHREAD_SERIALIZE 1
#define APR_HAS_FLOCK_SERIALIZE 0
#define APR_HAS_SYSVSEM_SERIALIZE 1
#define APR_HAS_FCNTL_SERIALIZE 1
#define APR_HAS_PROC_PTHREAD_SERIALIZE 1
#define APR_HAS_RWLOCK_SERIALIZE 0
#define APR_HAS_LOCK_CREATE_NP 1
(2) pthread_interproc is actually used in crossproc.c
Thanks,
--Cliff
Re: warnings with APR_USE_PROC_PTHREAD_SERIALIZE
Posted by rb...@covalent.net.
Does this solve the warnings?
Index: locks.h
===================================================================
RCS file: /home/cvs/apr/include/arch/unix/locks.h,v
retrieving revision 1.35
diff -u -d -b -w -u -r1.35 locks.h
--- locks.h 2001/07/01 05:49:44 1.35
+++ locks.h 2001/07/01 22:54:09
@@ -150,9 +150,8 @@
char *fname;
#if APR_HAS_SYSVSEM_SERIALIZE || APR_HAS_FCNTL_SERIALIZE ||
APR_HAS_FLOCK_SERIALIZE
int interproc;
-#endif
-#if APR_HAS_PROC_PTHREAD_SERIALIZE
- pthread_mutex_t *pthread_interproc;
+#elif APR_HAS_PROC_PTHREAD_SERIALIZE
+ pthread_mutex_t *interproc;
#endif
#if APR_HAS_THREADS
/* APR doesn't have threads, no sense in having an thread lock mechanism.
If so, please apply.
Ryan
On Sun, 1 Jul 2001, Cliff Woolley wrote:
>
> Just a heads up on some warnings I'm getting on Solaris 2.6 where
> APR_USE_PROC_PTHREAD_SERIALIZE is selected:
>
> locks.c: In function `apr_os_lock_get':
> locks.c:344: warning: assignment makes pointer from integer without a cast
> locks.c: In function `apr_os_lock_put':
> locks.c:365: warning: assignment makes integer from pointer without a cast
>
> The problem is that (after macro substitution) my apr_os_lock_t looks like
> this:
>
> struct apr_os_lock_t {
> pthread_mutex_t *crossproc;
> pthread_mutex_t *intraproc;
> };
>
> And apr_os_lock_get/put assume that crossproc will be an int (as it is
> with the other serialize methods).
>
> I'd work on this, but it'd probably be easier for somebody who's spent
> more time in the locking code than I have...
>
> --Cliff
>
>
>
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------