[...]
In the current apr_palloc, the lock is only around the call to new_block.
I think that's reasonable; new_block is manipulating a global
free list, so it has to be mutex-protected.
This triggered me to investigate the pools code again. It seems to me that
there is a possible race
Yes, there's definitely a race condition there. I noticed that
too, and I thought it was intentional (i.e., that the lack of a
lock was a conscious choice to avoid a performance penalty
for apps in which pools aren't shared across threads) and
harmless (because there aren't any pools in Apache
Henri Delebecque wrote:
hello,
I have an Alpha server under Digital Unix 4.0d , running (or trying to):
Apache 1.3.19
apr_20010627114532
Tomcat 4.0 b5
like Markus Mailinglists [EMAIL PROTECTED], I have
an error : Cannot load /usr.../mod_webapp.so into server: Unresolved
symbol in
hello,
I have an Alpha server under Digital Unix 4.0d , running (or trying to):
Apache 1.3.19
apr_20010627114532
Tomcat 4.0 b5
like Markus Mailinglists [EMAIL PROTECTED], I have
an error : Cannot load /usr.../mod_webapp.so into server: Unresolved
symbol in /usr.../libapr.so: __eprintf while I
Sooner or later, we are going to be writing the file someplace. That
could be the network, or it could be into memory to do some mucking with
the data. Since we are either dup'ing it or mmap'ing it, I figured we
could be conservative here and mmap the data. If we dup it here, and
