You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by st...@apache.org on 2003/09/28 01:51:46 UTC
cvs commit: apr/memory/unix apr_pools.c
striker 2003/09/27 16:51:46
Modified: misc/unix start.c
memory/unix apr_pools.c
Log:
* misc/unix/start.c
(apr_initialize): Remove atomics initialization from this function. Due
to circular dependency, doing it here is too late.
* memory/unix/apr_pools.c
(apr_pool_initialize): Add atomics initialization to the release and debug
versions. This has to happen here, since pools rely on mutexes, which
can be backed by atomics. Atomics initialization requires a pool.
Revision Changes Path
1.71 +6 -3 apr/misc/unix/start.c
Index: start.c
===================================================================
RCS file: /home/cvs/apr/misc/unix/start.c,v
retrieving revision 1.70
retrieving revision 1.71
diff -u -r1.70 -r1.71
--- start.c 6 Jan 2003 23:44:32 -0000 1.70
+++ start.c 27 Sep 2003 23:51:46 -0000 1.71
@@ -99,9 +99,12 @@
apr_pool_tag(pool, "apr_initialize");
- if ((status = apr_atomic_init(pool)) != APR_SUCCESS) {
- return status;
- }
+ /* apr_atomic_init() used to be called from here aswell.
+ * Pools rely on mutexes though, which can be backed by
+ * atomics. Due to this circular dependency
+ * apr_pool_initialize() is taking care of calling
+ * apr_atomic_init() at the correct time.
+ */
apr_signal_init(pool);
1.199 +14 -0 apr/memory/unix/apr_pools.c
Index: apr_pools.c
===================================================================
RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
retrieving revision 1.198
retrieving revision 1.199
diff -u -r1.198 -r1.199
--- apr_pools.c 3 Sep 2003 17:12:18 -0000 1.198
+++ apr_pools.c 27 Sep 2003 23:51:46 -0000 1.199
@@ -555,6 +555,13 @@
apr_pool_tag(global_pool, "apr_global_pool");
+ /* This has to happen here because mutexes might be backed by
+ * atomics. It used to be snug and safe in apr_initialize().
+ */
+ if ((rv = apr_atomic_init(global_pool)) != APR_SUCCESS) {
+ return rv;
+ }
+
#if APR_HAS_THREADS
{
apr_thread_mutex_t *mutex;
@@ -1265,6 +1272,13 @@
apr_pool_tag(global_pool, "APR global pool");
apr_pools_initialized = 1;
+
+ /* This has to happen here because mutexes might be backed by
+ * atomics. It used to be snug and safe in apr_initialize().
+ */
+ if ((rv = apr_atomic_init(global_pool)) != APR_SUCCESS) {
+ return rv;
+ }
#if (APR_POOL_DEBUG & APR_POOL_DEBUG_VERBOSE_ALL)
apr_file_open_stderr(&file_stderr, global_pool);
Re: cvs commit: apr/memory/unix apr_pools.c
Posted by Branko Čibej <br...@xbc.nu>.
Cliff Woolley wrote:
>On Mon, 29 Sep 2003, [UTF-8] Branko ?^Libej wrote:
>
>
>
>>>>Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
>>>>Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
>>>>dangling references to it in apr_pools.obj.
>>>>
>>>>
>>Uh -- I said HEAD, not the 0.9 branch.
>>
>>
>
>As a data point, the test builds I ran earlier today where I caught the
>missing #include "apr_atomic.h" in apr_pools.c were run on Linux. After
>including that, the warning about having no definition of
>apr_atomic_init() went away, so it must be getting _something_.
>
>
The linux build (probably) uses atomic/unix/apr_atomic.c. The Windows
build doesn't. Since I've been building the static library, this missing
reference isn't noticed until the library is actually used in a link.
Anyway, I'll wait until the author of the new atomics API can give me a
hint about the genericity of unix/apr_atomic.c. Looks O.K. to me, but I
can live on the branch for now and 4 a.m. isn't exactly the best time to
start experimenting.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: cvs commit: apr/memory/unix apr_pools.c
Posted by Cliff Woolley <jw...@virginia.edu>.
On Mon, 29 Sep 2003, [UTF-8] Branko �^Libej wrote:
> >>Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
> >>Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
> >>dangling references to it in apr_pools.obj.
>
> Uh -- I said HEAD, not the 0.9 branch.
As a data point, the test builds I ran earlier today where I caught the
missing #include "apr_atomic.h" in apr_pools.c were run on Linux. After
including that, the warning about having no definition of
apr_atomic_init() went away, so it must be getting _something_.
--Cliff
RE: cvs commit: apr/memory/unix apr_pools.c
Posted by Sander Striker <st...@apache.org>.
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: Monday, September 29, 2003 3:31 AM
[...]
> >Looks like a definition to me... Why doesn't this work?
> >
> >
> Uh -- I said HEAD, not the 0.9 branch.
Doh.
>>> Since there's a whole bunch of atomics that do _not_ have a
>>> Win32-specific implementation in apr_atomic.h, my guess is that we need
>>> to build apr_atomic.c on Windows.
Worth a shot. It looks generic enough.
Sander
Re: cvs commit: apr/memory/unix apr_pools.c
Posted by Branko Čibej <br...@xbc.nu>.
Sander Striker wrote:
>>From: Branko Cibej [mailto:brane@xbc.nu]
>>Sent: Monday, September 29, 2003 3:22 AM
>>
>>
>
>
>
>>Branko Čibej wrote:
>>
>>
>>
>>>Also, I'm being double stupid because it's not APR that doesn't compile,
>>>it's APR-iconv. Ho hum. Now how can that happen?
>>>
>>>/me grumbles and looks
>>>
>>>
>>>
>>>
>>Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
>>Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
>>dangling references to it in apr_pools.obj.
>>
>>
>
>Huh?
>
>#if defined(WIN32)
>
>#define apr_atomic_t LONG
>
>#define apr_atomic_add(mem, val) InterlockedExchangeAdd(mem,val)
>#define apr_atomic_dec(mem) InterlockedDecrement(mem)
>#define apr_atomic_inc(mem) InterlockedIncrement(mem)
>#define apr_atomic_set(mem, val) InterlockedExchange(mem, val)
>#define apr_atomic_read(mem) (*mem)
>#define apr_atomic_cas(mem,with,cmp) InterlockedCompareExchange(mem,with,cmp)
>#define apr_atomic_init(pool) APR_SUCCESS
>#define apr_atomic_casptr(mem,with,cmp) InterlockedCompareExchangePointer(mem,with,cmp)
>
>Looks like a definition to me... Why doesn't this work?
>
>
Uh -- I said HEAD, not the 0.9 branch.
>
>
>
>>Since there's a whole bunch of atomics that do _not_ have a
>>Win32-specific implementation in apr_atomic.h, my guess is that we need
>>to build apr_atomic.c on Windows.
>>
>>
>
>Isn't the above the full atomics API?
>
>
>Sander 'getting confused now'
>
>
>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
RE: cvs commit: apr/memory/unix apr_pools.c
Posted by Sander Striker <st...@apache.org>.
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: Monday, September 29, 2003 3:22 AM
> Branko Čibej wrote:
>
> >Also, I'm being double stupid because it's not APR that doesn't compile,
> >it's APR-iconv. Ho hum. Now how can that happen?
> >
> >/me grumbles and looks
> >
> >
>
> Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
> Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
> dangling references to it in apr_pools.obj.
Huh?
#if defined(WIN32)
#define apr_atomic_t LONG
#define apr_atomic_add(mem, val) InterlockedExchangeAdd(mem,val)
#define apr_atomic_dec(mem) InterlockedDecrement(mem)
#define apr_atomic_inc(mem) InterlockedIncrement(mem)
#define apr_atomic_set(mem, val) InterlockedExchange(mem, val)
#define apr_atomic_read(mem) (*mem)
#define apr_atomic_cas(mem,with,cmp) InterlockedCompareExchange(mem,with,cmp)
#define apr_atomic_init(pool) APR_SUCCESS
#define apr_atomic_casptr(mem,with,cmp) InterlockedCompareExchangePointer(mem,with,cmp)
Looks like a definition to me... Why doesn't this work?
> Since there's a whole bunch of atomics that do _not_ have a
> Win32-specific implementation in apr_atomic.h, my guess is that we need
> to build apr_atomic.c on Windows.
Isn't the above the full atomics API?
Sander 'getting confused now'
Re: cvs commit: apr/memory/unix apr_pools.c
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
>Also, I'm being double stupid because it's not APR that doesn't compile,
>it's APR-iconv. Ho hum. Now how can that happen?
>
>/me grumbles and looks
>
>
Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
dangling references to it in apr_pools.obj.
Since there's a whole bunch of atomics that do _not_ have a
Win32-specific implementation in apr_atomic.h, my guess is that we need
to build apr_atomic.c on Windows.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: cvs commit: apr/memory/unix apr_pools.c
Posted by Branko Čibej <br...@xbc.nu>.
Sander Striker wrote:
>>From: Branko Cibej [mailto:brane@xbc.nu]
>>Sent: Monday, September 29, 2003 2:56 AM
>>
>>
>
>
>
>>[snip]
>>
>>I can't believe we don't have a Win32 implementation of the atomics. So
>>right now, HEAD doesn't compile on Windows. :-(
>>
>>
>
>Sure we do. Take a look at include/apr_atomic.h
>
>
Hm, right, ouch, sorry, silly me.
>Is the implementation in unix/ generic enough to work anywhere? If it
>is, I'll temporarily add it to apr.dsp.
>
>
>
>No need. The include file redefines about everything AFAICT.
>
>
Also, I'm being double stupid because it's not APR that doesn't compile,
it's APR-iconv. Ho hum. Now how can that happen?
/me grumbles and looks
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
RE: cvs commit: apr/memory/unix apr_pools.c
Posted by Sander Striker <st...@apache.org>.
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: Monday, September 29, 2003 2:56 AM
> [snip]
>
> I can't believe we don't have a Win32 implementation of the atomics. So
> right now, HEAD doesn't compile on Windows. :-(
Sure we do. Take a look at include/apr_atomic.h
> Is the implementation in unix/ generic enough to work anywhere? If it
> is, I'll temporarily add it to apr.dsp.
No need. The include file redefines about everything AFAICT.
Sander
Re: cvs commit: apr/memory/unix apr_pools.c
Posted by Branko Čibej <br...@xbc.nu>.
striker@apache.org wrote:
>striker 2003/09/27 16:51:46
>
> Modified: misc/unix start.c
> memory/unix apr_pools.c
> Log:
> * misc/unix/start.c
>
> (apr_initialize): Remove atomics initialization from this function. Due
> to circular dependency, doing it here is too late.
>
> * memory/unix/apr_pools.c
>
> (apr_pool_initialize): Add atomics initialization to the release and debug
> versions. This has to happen here, since pools rely on mutexes, which
> can be backed by atomics. Atomics initialization requires a pool.
>
>
[snip]
I can't believe we don't have a Win32 implementation of the atomics. So
right now, HEAD doesn't compile on Windows. :-(
Is the implementation in unix/ generic enough to work anywhere? If it
is, I'll temporarily add it to apr.dsp.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/