On Thu, 2008-08-07 at 15:08 -0500, William A. Rowe, Jr. wrote:
Here's an offer, I'll tag and roll 24 hours from now unless someone tells me
that the API remains broken w.r.t. reslist etc.
Not broken. In fact, the trunk changes have been addressed in an
entirely backward compatible way.
On the back of PR 45513
(https://issues.apache.org/bugzilla/show_bug.cgi?id=45513), shouldn't we
be moving that piece of code that manually overrides detection for
particular platforms to the very end, like we had it in 1.2.x?
Patch is attached. Please review, as it would be a good idea to put
On Fri, 2008-08-08 at 07:46 +1000, Bojan Smojver wrote:
On the back of PR 45513
(https://issues.apache.org/bugzilla/show_bug.cgi?id=45513)
Looks like this was busted in
http://svn.apache.org/viewvc?view=revrevision=554963
--
Bojan
On Fri, 2008-08-08 at 00:42 +0200, Peter Poeml wrote:
I am a heavy user of both mod_dbd and apr_memcache, and I'm
investigating an apr_memcache related memleak right now that I started
getting with 1.3.0, so I will give this a good testing in the next few
hours.
Latest patch for memcache
On Fri, 2008-08-08 at 07:46 +1000, Bojan Smojver wrote:
Patch is attached.
Just got feedback from the original bug reporter (Rainer Jung) and the
attached patch is incorrect. So, here is the patch submitted with the
bug report that fixes the issue on Solaris.
--
Bojan
--- configure.in-orig
On Fri, 2008-08-08 at 08:58 +1000, Bojan Smojver wrote:
Latest patch for memcache leak is attached.
That's for 1.3.x. The trunk should be OK, because it relies on
pre_cleanup.
PS. If the list thinks that it is better to have
apr_reslist_cleanup_order_set() in 1.3.x as non-public API
On Fri, 2008-08-08 at 01:40 +0200, Peter Poeml wrote:
That patch does the job as well.
OK, thanks. Committed to 1.3.x now in r683756.
Folks, this commit is quite obviously a hack around limitations of
reslist in 1.3.x. If the list decides it is better that we have
On Thu, 2008-08-07 at 17:55 -0500, William A. Rowe, Jr. wrote:
Thanks Peter, it begs the question from my last note, should we refuse
any 2.62 for packaging via our scripts, or just let it slide?
My gutcheck says simply refuse 2.62.
I would generate our configure with 2.61 (for which we
On Fri, 2008-08-08 at 03:45 +0200, Peter Poeml wrote:
So the usual stability of the
API isn't so important (yet) in my opionion.
The new API in reslist that switches the behaviour of cleanups cannot be
made public in 1.3.x, due to our versioning rules. But, we could do that
internally, if
On Fri, 2008-08-08 at 04:33 +, [EMAIL PROTECTED] wrote:
Warn reslist users of potential dangers related to sub-pool creation.
I did this for 1.3.x only on purpose. Trunk should probably get a
different comment.
--
Bojan
On Wed, 2008-08-06 at 12:46 +0200, Ruediger Pluem wrote:
I am worried about the case that the destructor might allocate
memory from the pool for temporary purposes (ok that would be a
memory leak in the long run).
Not only that, but if you have a look at testreslist.c, you'll find
this:
On Wed, 2008-08-06 at 12:27 +0200, Mladen Turk wrote:
The major problem with invalidate is that blocking
destructors (socket shutdown for example)
are serialized, meaning that closing 100 sockets
is done one at a time instead by owning threads in
parallel.
Why don't you instead shut the
On Tue, 2008-08-05 at 14:57 -0500, William A. Rowe, Jr. wrote:
You have it upside down though, apr_file_inherit_[un]set should toggle
the CLOEXEC flag.
I was thinking something like this (untested).
--
Bojan
Index: file_io/unix/open.c
On Wed, 2008-08-06 at 14:00 +1000, Bojan Smojver wrote:
I was thinking something like this (untested).
Probably not complete. I guess we should check in file_cleanup() if the
error on close() is EBADF and not report it if O_CLOEXEC is defined. Or
something like that...
--
Bojan
After reading this article on LWN: http://lwn.net/Articles/292559/, it
occurred to me that it may be useful to pass this flag to open in
apr_file_open() on platforms that support it, in case someone decides to
fork()/execve() by non-APR means.
Of course, apr_file_inherit_[un]set() would have to
Quoting Joe Orton [EMAIL PROTECTED]:
I'd rather the decision was made by those who are more familiar with
this code than I. The fact that this change apparently does break an
existing caller does seem to back up the API change argument:
http://markmail.org/message/xjgaampnoru67pxr
I wasn't
On Wed, 2008-07-30 at 06:53 -0400, Tom Donovan wrote:
Calling sqlite3_busy_timeout() in dbd_sqlite3_open might be better than using
the
do { ... apr_sleep() ... }
loop in dbd_sqlite3_select_internal.
Yeah, true. I may just rework it with that instead. Thanks for the hint!
Nevertheless,
On Thu, 2008-07-31 at 07:30 +1000, Bojan Smojver wrote:
I may just rework it with that instead.
On second thought, it may not be that simple, given the DBD mutex we
have in place...
--
Bojan
On Thu, 2008-07-31 at 07:30 +1000, Bojan Smojver wrote:
I could get about 40 times as many pages out.
Eh, not true, actually. Never mind - please ignore me :-(
--
Bojan
On Mon, 2008-07-28 at 20:45 +0200, Ruediger Pluem wrote:
Hm, of course still a lot of overhead to manage a single resource.
True. I first started writing the patch with just a (void *) pointing to
the resource, but then I realized that ttl actually may be useful for
recycling it. So, rather
On Mon, 2008-07-28 at 12:27 +0200, Mladen Turk wrote:
I plan to thoroughly test those changes against httpd this week.
So lets wait for a while. If that stops tagging 1.3.x, we can
postpone that for next tag.
OK. I'm also hoping we'll hear from others.
--
Bojan
On Mon, 2008-07-28 at 23:51 +0100, Joe Orton wrote:
It does seem like existing callers could reasonably depend on the
existing behaviour, and that changing it would break them.
The situation is quite complicated. Tricks like the ones from mod_dbd
(or malloc()/free() container + zero sub-pool
I think we should be a little bit more strict when it comes to resource
limits in reslist code. As per attached, it should not be possible to
set min to less than zero and hmax to zero, as both don't make sense.
Comments?
--
Bojan
Index: misc/apr_reslist.c
On Sun, 2008-07-27 at 13:50 +0100, Nick Kew wrote:
+1.
Here is a rough sketch, so please review. Please note the enforcement of
min, smax and hmax to 1.
--
Bojan
Index: include/apr_reslist.h
===
--- include/apr_reslist.h
On Sun, 2008-07-27 at 20:05 -0400, Bob Rossi wrote:
Ping. Anything I can do to help?
I think Bill had that one. He's a busy guy though, so it may be a
while...
PS. I'm not familiar with that platform at all, so I can't help :-(
--
Bojan
On Sun, 2008-07-27 at 19:19 -0500, William A. Rowe, Jr. wrote:
Or more to the point, when is 1.3.x ready to ship w.r.t. reslist? You'll
note there hasn't been a 1.3.3 tag since I've been watching all of this
activity, and didn't want to rush anyone.
There are several things that we can do
On Mon, 2008-07-28 at 10:30 +1000, Bojan Smojver wrote:
- implement when no_threads (patch also available)
Hmm, on second thought, it may be against the rules to backport this to
1.3.x.
If someone were to compile a program against 1.3.3 on a platform with no
threads, this program would not run
On Fri, 2008-07-25 at 00:17 +, [EMAIL PROTECTED] wrote:
Add apr_file_link() function.
PR 44841.
Patch by Mark Heily mark heily.com
Folks, this addition includes Windows code, which I am unable to review
at all (Unix code is very simple, though). So, I'm relying on CTR here!
--
Bojan
On Thu, 2008-07-24 at 23:35 -0400, Tom Donovan wrote:
I moved apr_file_link() to open.c for all platforms - r679652.
Also moved the tests to testfile vs. testfilecopy.
unix/copy.c is currently used for both unix windows, as it had no
platform-specific code before this.
Ah, wasn't aware
On Thu, 2008-07-17 at 05:45 +, [EMAIL PROTECTED] wrote:
Use apr_pool_pre_cleanup_register for reslist cleanup
Coming back to the original commit message and given the discussion on
the list, are we backporting this to 1.3.x or not?
--
Bojan
On Tue, 2008-07-22 at 09:15 +0100, Joe Orton wrote:
Here's how I would do it:
Here is a rough sketch.
--
Bojan
Index: misc/apr_reslist.c
===
--- misc/apr_reslist.c (revision 678599)
+++ misc/apr_reslist.c (working copy)
@@ -14,8
On Wed, 2008-07-23 at 16:12 +1000, Bojan Smojver wrote:
Here is a rough sketch.
As Joe predicted, it even works when pool pointer is not reset.
--
Bojan
Index: misc/apr_reslist.c
===
--- misc/apr_reslist.c (revision 678599
On Wed, 2008-07-23 at 08:34 +0200, Mladen Turk wrote:
If you create a socket for example in the constructor,
socket registers it's own cleanup. This cleanup will be run
*before* destructor meaning you are convicted to apr_socket_close,
and you cannot cleanly close the socket via shutdown, or
On Tue, 2008-07-22 at 09:15 +0100, Joe Orton wrote:
There is a design pattern (if you can call it that) in APR which is
important to maintain: object destructors must be implemented as, or
wrapped in, a pool cleanup, and must only ever be invoked by running
that cleanup. You see that in
On Wed, 2008-07-23 at 08:56 +0200, Mladen Turk wrote:
Cannot do that. Cleanups are LIFO. First cleanup registered is res_clean
so it'll always be executed *last*.
I wasn't talking about res_clean.
Socket cleanup is private, so
cannot modify that.
When you create your socket with
On Wed, 2008-07-23 at 17:00 +1000, Bojan Smojver wrote:
When you create your socket with apr_socket_create(), there is a pool
argument there. If you hang a cleanup off it, it will run before close()
in socket_cleanup().
Example constructor:
--
struct my_socket_t
On Wed, 2008-07-23 at 09:23 +0200, Mladen Turk wrote:
What do you mean by hang a cleanup off it?
See my example constructor.
Socket cleanup is private function and cannot be modified.
Of course.
constructor(res, pool) {
res-sock = socket_create(pool)
}
destructor(res) {
On Wed, 2008-07-23 at 16:21 +1000, Bojan Smojver wrote:
As Joe predicted, it even works when pool pointer is not reset.
Just some minor cleanups.
--
Bojan
Index: misc/apr_reslist.c
===
--- misc/apr_reslist.c (revision 679009
On Wed, 2008-07-23 at 11:23 +0200, Mladen Turk wrote:
Well but what if I need that pool in destructor?
It'll be long gone before destructor is called.
That's the whole design pattern argument. If you follow the design
pattern, you won't need it there.
IMHO reslist should do what is says:
Quoting Mladen Turk [EMAIL PROTECTED]:
With Joe's proposal the additional pool for reslist and the
single cleanup registered there is actually the pre_cleanup,
so why not using that? We'll preserve 8K of memory to the user
simply by using that.
I'll try to summarise like this:
- pre_cleanup
On Wed, 2008-07-23 at 21:23 +0200, Ruediger Pluem wrote:
Wouldn't it be better to keep the resource specific pools and just
do an apr_pool_clear instead of the apr_pool_create / apr_pool_destroy
cycle?
Only if you wanted code to run fast :-)
--
Bojan
On Wed, 2008-07-23 at 16:22 +0200, Mladen Turk wrote:
Without a need to create an extra pool and making sure
it's a last one. Nothing more.
Except that in the case of reslist you _already_ have that per resource
pool created by the user (that's where the problem comes from in the
first place).
On Wed, 2008-07-23 at 21:23 +0200, Ruediger Pluem wrote:
Wouldn't it be better to keep the resource specific pools and just
do an apr_pool_clear instead of the apr_pool_create / apr_pool_destroy
cycle?
Seriously for a second, with resource lists the caller is in charge of
deciding how many
On Wed, 2008-07-23 at 13:00 +0100, Joe Orton wrote:
But that does make the destructor a bit redundant
Just a quick an dirty.
--
Bojan
Index: libaprutil.dsp
===
--- libaprutil.dsp (revision 679250)
+++ libaprutil.dsp (working
On Thu, 2008-07-24 at 11:04 +1000, Bojan Smojver wrote:
Just a quick an dirty.
OOPS! Forgotten testrespool.c.
--
Bojan
Index: libaprutil.dsp
===
--- libaprutil.dsp (revision 679258)
+++ libaprutil.dsp (working copy)
@@ -384,6
On Wed, 2008-07-23 at 17:57 +1000, Bojan Smojver wrote:
Just some minor cleanups.
For the record, that would be leaking memory in _invalidate. The
attached should address that.
--
Bojan
Index: misc/apr_reslist.c
===
--- misc
On Tue, 2008-07-22 at 16:12 +1000, Bojan Smojver wrote:
+if (pool-is_volatile) {
Nah, that wouldn't work if pool has been destroyed already. I'm trying
to avoid adding locking on all pool destruction, as you can see.
--
Bojan
On Tue, 2008-07-22 at 16:22 +1000, Bojan Smojver wrote:
Nah, that wouldn't work if pool has been destroyed already. I'm trying
to avoid adding locking on all pool destruction, as you can see.
Oh, and the patch that I sent was an incomplete version anyway :-(
--
Bojan
On Tue, 2008-07-22 at 08:42 +0200, Mladen Turk wrote:
In the original pool_destroy the pool-sibling access is guarded
by mutex. Since in multithreaded environment child pool might be in
the middle of destroy process detaching himself, think you'll have
to guard the access to pool-sibling in
On Tue, 2008-07-22 at 06:43 +, [EMAIL PROTECTED] wrote:
Give MySQL DBD driver reconnect option.
PR 45407.
I would really like to backport this one to 1.3.x before 1.3.x. It is
affecting mod_dbd with MySQL driver, when connections go away.
Please review.
--
Bojan
On Tue, 2008-07-22 at 16:53 +1000, Bojan Smojver wrote:
I would really like to backport this one to 1.3.x before 1.3.x.
That should be before 1.3.3, of course.
--
Bojan
On Tue, 2008-07-22 at 09:12 +0200, Sander Striker wrote:
Note that pools are specifically *not* thread safe. Only one thread
can 'own' a pool at a time, and when there are subpools on another
thread, you'd better protect those subpools from not being destroyed
while that thread is running.
On Tue, 2008-07-22 at 11:11 +0200, Mladen Turk wrote:
If the user creates a subpool the problem will still be present because
this sub pool will be destroyed before the destructor is called.
Also any resource allocated from this pool will be destroyed in advance
to the destructor (since its
On Wed, 2008-07-23 at 02:58 +, [EMAIL PROTECTED] wrote:
Round out 675817 by avoiding a skip of a 'special' last element
APU_DSO_LIBDIR where none existed.
Thanks Bill! I didn't take that one into account at all.
--
Bojan
On Mon, 2008-07-21 at 07:34 +0200, Mladen Turk wrote:
Although IMHO it makes reslist API behave like it should
Agreed.
it might
break some of the existing usages where users were doing nasty tricks
with reslist to make the things not to leak memory.
Yeah, that's what I was worried about as
On Mon, 2008-07-21 at 09:24 +0200, Mladen Turk wrote:
Since we use pools, this can be achieved only by creating a separate
pool for each accepted socked that will be destroyed once the
socket is not needed any more.
Somewhat related... I kind of remember a discussion about every new pool
Quoting Mladen Turk [EMAIL PROTECTED]:
I still don't know how to solve that problem effectively, so
any ideas are welcome.
How about we have apr_pool_destroy_safe(). We give it two arguments:
- pool to kill
- root pool to start searching from (NULL means global pool)
Then we first check if
On Mon, 2008-07-21 at 09:24 +0200, Mladen Turk wrote:
C = apr_pool_create(P)
So, before this we have (because it's P that gets whacked out or order
in our example):
R = apr_pool_parent_get(P)
...apr_pool_destroy(C) = !CORE
This then becomes:
apr_pool_destroy_safe(C,
On Mon, 2008-07-21 at 21:16 +1000, Bojan Smojver wrote:
How about we have apr_pool_destroy_safe(). We give it two arguments:
For example... Don't mind the details, especially locks - they are most
likely all screwed up.
--
Bojan
Index: memory/unix/apr_pools.c
On Mon, 2008-07-21 at 12:01 +0100, Joe Orton wrote:
I still don't understand the problem at all. Can you give an example of
something which cannot be done today because of the current design of
APR pools?
I think it's not so much that it cannot be done, just that it becomes a
bit of a head
On Mon, 2008-07-21 at 10:11 -0700, Chris Darroch wrote:
See also the notes in mod_dbd.c in dbd_setup() and the workaround
involving the destructor dbd_destruct(), a flag variable, and
a second cleanup function dbd_destroy() registered on the parent pool
(i.e., P) after the reslist is
On Tue, 2008-07-22 at 07:29 +1000, Bojan Smojver wrote:
Or you can malloc() the resource container in the constructor (i.e. rec
in dbd_construct()) and then free() it in destructor.
Something like this. Completely untested, of course :-)
--
Bojan
Index: modules/database/mod_dbd.c
On Mon, 2008-07-21 at 22:05 +1000, Bojan Smojver wrote:
For example...
After thinking about it a bit more, it appears that we really should not
need to fiddle with locking here. Essentially, when we call this, we can
assume that root pool and below will not be modified by another thread
On Mon, 2008-07-21 at 17:00 -0700, Chris Darroch wrote:
I'm going to have to bow out here but I guess my main concern
is that it's not unreasonable for developers to assume APR reslists
and pools should play well together, and they really don't, at
present -- you either have to resort to
On Sun, 2008-07-20 at 21:29 +, [EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?rev=678323view=rev
Log:
Close memory leak.
This, of course, has to do with pre_cleanups now working and being used
for reslists.
Mladen,
I'm not sure if you're planning on backporting pre_cleanup
On Sat, 2008-07-19 at 06:12 +0200, Mladen Turk wrote:
But not with pre_cleanup.
Could you try running this? I get an infinite loop (CPU pegged at 100%)
even with pre_cleanup.
If I change the code to this:
apr_reslist_create(list,0,10,10,0,con,de,NULL,pool);
I get double free.
Either that
On Sat, 2008-07-19 at 13:55 +0200, Mladen Turk wrote:
Me as well. There was an bug in apr_pool.
Now it works as expected.
Yep, I can confirm that too, with both of my test programs. Thanks for
the fix!
BTW, shouldn't the comment say constructor in this sentence of
apr_reslist.c:
If an child
On Sat, 2008-07-19 at 14:46 +0100, Nick Kew wrote:
Which begs the question, how did the typo get in to 1.3?
I think it probably has to do with the fact that, as introduced, the
code worked (by accident) in many cases. Without doing the tests of the
last few days, it would have been really hard
Quoting Bojan Smojver [EMAIL PROTECTED]:
PPS. The situation I was referring to in my previous e-mails cannot
actually happen. R always outlives S.
This e-mail was written before pre_cleanup bug in apr_pools.c was
fixed, hence my PPS. However, let me reiterate one point: if people
hang
Quoting Bojan Smojver [EMAIL PROTECTED]:
The above will lead in the subsequent sub-pool destruction (through the
regular pool machinery) to segfaults (because that cleanup will refer
to already destroyed resource).
Of course, depending on resource list creation parameters, the above
may
On Fri, 2008-07-18 at 14:51 +1000, Bojan Smojver wrote:
What do you mean by random?
Called like this, it crashes (infinite recursion):
apr_reslist_create(list,0,10,10,0,con,de,NULL,pool);
Hmm, not safe after all...
--
Bojan
On Fri, 2008-07-18 at 15:59 +1000, Bojan Smojver wrote:
Hmm, not safe after all...
OK, I'm going to stop spamming the list now. I promise...
This appears to work with both pre and regular cleanup. The trick is to
zero the pool pointer in the resource cleanup function, so that
destructor can
On Fri, 2008-07-18 at 16:30 +1000, Bojan Smojver wrote:
*r=apr_pcalloc(rpool,sizeof(**r));
This should really be malloc()'ed and free in de().
--
Bojan
Quoting Mladen Turk [EMAIL PROTECTED]:
Of course if you can do that.
You can always do that, because it only applies to the resource
container, which must survive in order for de() to check for r-p
(where r is resource container and p the sub-pool in question).
PS. The code works (by
On Fri, 2008-07-18 at 12:34 +0200, Mladen Turk wrote:
For example apr_memcache.c leeks memory because
it doesn't call apr_pool_destroy in destructor
although it creates one in constructor.
(Probably because with standard cleanup it cores)
Does this solve it?
--
Bojan
Index:
On Sat, 2008-07-19 at 08:59 +1000, Bojan Smojver wrote:
Does this solve it?
Eh, sorry - not being careful enough with that cleanup registration.
This should be better.
--
Bojan
Index: memcache/apr_memcache.c
===
--- memcache
On Sat, 2008-07-19 at 09:08 +1000, Bojan Smojver wrote:
This should be better.
Third time's the charm? I keep forgetting that by the time destructor is
called, pool may be dead and buried already...
--
Bojan
Index: memcache/apr_memcache.c
On Thu, 2008-07-17 at 05:45 +, [EMAIL PROTECTED] wrote:
+ * If an child pool was created inside apr_reslist_destructor
I get what you're trying to do with the patch, but can't the destructor
just allocate memory from that pool and not create a child pool?
--
Bojan
On Thu, 2008-07-17 at 17:30 +1000, Bojan Smojver wrote:
I get what you're trying to do with the patch, but can't the destructor
just allocate memory from that pool and not create a child pool?
Ah, never mind me... Destructor can get called many times, hence the
child pool.
--
Bojan
Quoting jean-frederic clere [EMAIL PROTECTED]:
I will have a look later, any hints in the meantime?
That was fixed in r677523.
--
Bojan
Quoting [EMAIL PROTECTED]:
Use apr_pool_pre_cleanup_register for reslist cleanup
After thinking about this a bit more, this patch may introduce a
somewhat unusual (possibly even dangerous) behaviour, as it changes
the way cleanups normally work with APR pools.
Imagine a resource R, that
Quoting Mladen Turk [EMAIL PROTECTED]:
So the pool P is not destroyed before its subpools, only
the callback is called before subpools are destroyed.
True, but that's not what I see as the problem.
Imagine R is a database connection and S a prepared statement that
depends on R (i.e. uses
On Thu, 2008-07-17 at 13:59 +0200, Mladen Turk wrote:
So the destructor *must not* call apr_pool_destroy(subpool)
if the parent pool is inside apr_pool_destroy (tricky).
You're right. In fact, this is the situation regardless of how the
cleanup is registered (pre or not). The attached program
On Fri, 2008-07-18 at 11:20 +1000, Bojan Smojver wrote:
The attached program crashes (double free) with or without that
change.
He, he... It's always good to go through code again. There was a bug in
the test program that caused it to crash. The attached program runs fine
with pre cleanup
On Fri, 2008-07-18 at 06:25 +0200, Mladen Turk wrote:
With regular cleanup this should core.
It doesn't here, not even when I do millions loops (i.e. with your k
index and explicit apr_pool_destroy(pool));
Try to random acquire/release resources and do few loops.
What do you mean by random?
On Wed, 2008-07-09 at 08:51 +0200, Mladen Turk wrote:
Hmm, trunk should be development version, so the API is not fixed
unlike once when branched.
In which case we'll have to remember to put that back in if we ever
decide to branch 1.4.0 from the trunk. What's the harm in keeping it for
now?
On Tue, 2008-07-08 at 17:18 -0400, Philip M. Gollucci wrote:
+CPPFLAGS=$save_cppflags
+LDFLAGS=$save_ldflags
+LIBS=$save_libs
Committed with quotes applied above. Thanks for the patch!
--
Bojan
On Wed, 2008-07-09 at 07:27 +0200, Mladen Turk wrote:
What about trunk? Do we need depreciation there as well.
I suppose not, cause it wasn't released.
Trunk is currently marked 1.4.0, so I guess yes - you should have
deprecated function there too. If/when trunk officially goes 2.0, then
we
On Mon, 2008-06-30 at 12:17 -0500, William A. Rowe, Jr. wrote:
Guys, please take a look, looks like one of the 1.3.x generation patches
has broken our API compatibility rules.
I'll bet $5 that this broke it:
http://svn.apache.org/viewvc/apr/apr/trunk/include/apr_ring.h?r1=566349r2=662299
On Tue, 2008-07-01 at 07:26 +1000, Bojan Smojver wrote:
I'll bet $5 that this broke it:
Yep, GCC will say:
error: request for member 'next' in something not a structure or union
--
Bojan
On Mon, 2008-06-30 at 15:12 -0500, William A. Rowe, Jr. wrote:
Are there any other showstoppers to trying a 1.3.3 release that folks will
volunteer to solve in the very near term?
I have all tests passing on Fedora 9 i686 for both APR and APU for 1.3.x
branch. I don't see any new Bugzilla
On Tue, 2008-07-01 at 07:26 +1000, Bojan Smojver wrote:
http://svn.apache.org/viewvc/apr/apr/trunk/include/apr_ring.h?r1=566349r2=662299
BTW, this calls for docs regeneration, so that people can see what that
macro actually does. I'll do that once we release 1.3.3.
--
Bojan
On Tue, 2008-06-24 at 14:45 -0600, Steve Comstock wrote:
1. Should I delete the srclib/apr and srclib/apr-util
directories I built just yesterday? Remember, the
configure took me over five hours to build what I
have (and it doesn't work)
You don't need to delete it, but
On Wed, 2008-06-25 at 09:26 +1000, Bojan Smojver wrote:
Given that this runs for such a long time, it would
really be better to do it on the hardware, rather than an emulator.
Otherwise, it may take you weeks before you find out what's going on :-(
One more note here. If you would like to see
On Tue, 2008-06-24 at 18:24 +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
I'm attaching the patch which adds support for Berkeley DB 4.7.
Thank you. Committed to trunk and 1.3.x.
--
Bojan
On Tue, 2008-06-24 at 11:16 -0400, Philip M. Gollucci wrote:
This list is based on FreeBSD ports tree, and my previous employer
(Ticketmaster).
I'm pretty sure open source folks won't mind being linked from this APR
page, but are Ticketmaster OK with it?
--
Bojan
On Tue, 2008-06-24 at 19:03 -0600, Steve Comstock wrote:
but that's one reason I'm so pissed: apparently the version shipped
with httpd is not the correct version. This would never be tolerated
in the mainframe world.
1.3.0 was the best version at the time of the httpd-2.2.9 release, so
httpd
On Tue, 2008-06-24 at 19:41 -0600, Steve Comstock wrote:
Why wasnt apr-1.3.2
included in the httpd-2.2.9 tarball, I guess is what I'm
asking.
Simply release timing, nothing else.
In fact, you'll find that many Linux and BSD distributions ship httpd
and APR/APU packages separately, so they can
On Tue, 2008-06-24 at 23:24 -0400, Philip M. Gollucci wrote:
I can ask, I see no reason why not, its not like its a secret they use
ASF software.
That would be great, thanks.
--
Bojan
On Fri, 2008-06-20 at 00:00 -0600, Steve Comstock wrote:
But I'll have to test it in the morning, it's late
here in Denver.
No worries. I also found this on the 'net, which may indirectly help you
(Subversion is a bit of cousin to APR/APU):
http://svn.haxx.se/users/archive-2006-11/0063.shtml
301 - 400 of 930 matches
Mail list logo
