dreid 01/06/07 17:44:52
Modified:include apr_sms.h
memory/unix apr_sms.c apr_sms_std.c apr_sms_tracking.c
Log:
Some tidying up of the locking code.
Move where we allocate the pool from and clean it up.
Change the pre_destroy to be an apr_status_t
Yes,
On Fri, 8 Jun 2001, Sander Striker wrote:
Oh, yes, I actually want to do s/mem_sys/sms/ aswell, but that can
I'm hoping that includes the foo_mem_sys's that are in the apr_sms_t
structure? sms-parent_mem_sys etc seems both redunant and too much
typing. sms-parent would be ideal, but then
From: David Reid [EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 5:19 PM
We could implement pool using sms but we'd loose a great deal of flexibility
and a great opportunity to make APR even more useful.
As each sms has the opportunity to control exactly how it locks, allocates,
frees and
On Fri, Jun 08, 2001 at 12:32:04AM -0400, Cliff Woolley wrote:
On Fri, 8 Jun 2001, Sander Striker wrote:
Oh, yes, I actually want to do s/mem_sys/sms/ aswell, but that can
I'm hoping that includes the foo_mem_sys's that are in the apr_sms_t
structure? sms-parent_mem_sys etc seems both
On Fri, Jun 08, 2001 at 12:32:04AM -0400, Cliff Woolley wrote:
On Fri, 8 Jun 2001, Sander Striker wrote:
Oh, yes, I actually want to do s/mem_sys/sms/ aswell, but that can
I'm hoping that includes the foo_mem_sys's that are in the apr_sms_t
structure? sms-parent_mem_sys etc seems
I am well beyond 100% in support of the sms schema. The only
question is what is which, do we wrap the pool schema in sms,
or do 'pools' become sms?
I'll try and write up a comparison between the apis in the weekend,
together with how it could be handled _if_ pools are replaced with
sms. If
On Fri, Jun 08, 2001 at 11:09:39AM +0200, Sander Striker wrote:
Greg Stein wrote:
On Fri, Jun 08, 2001 at 12:32:04AM -0400, Cliff Woolley wrote:
...
sms-parent would be ideal, but then again sms-ref wouldn't
make much sense
They should be:
-parent
-next_sibling (-next and
On Fri, Jun 08, 2001 at 11:09:42AM +0200, Sander Striker wrote:
I am well beyond 100% in support of the sms schema. The only
question is what is which, do we wrap the pool schema in sms,
or do 'pools' become sms?
I'll try and write up a comparison between the apis in the weekend,
[..]
Yes, but you are missing something here. You would have to create
a list header to nest in the apr_sms_t structure. With the ref
concept you don't need that, because it can point to parent-child.
I'm not sure that I follow. We have a complete set of
navigational pointers:
parent,
On Fri, Jun 08, 2001 at 11:09:42AM +0200, Sander Striker wrote:
I am well beyond 100% in support of the sms schema. The only
question is what is which, do we wrap the pool schema in sms,
or do 'pools' become sms?
I'll try and write up a comparison between the apis in the weekend,
Well I did say I wouldn't get back into this debate for a while, but...
On Fri, Jun 08, 2001 at 11:09:42AM +0200, Sander Striker wrote:
I am well beyond 100% in support of the sms schema. The only
question is what is which, do we wrap the pool schema in sms,
or do 'pools' become sms?
Well I did say I wouldn't get back into this debate for a while, but...
On Fri, Jun 08, 2001 at 11:09:42AM +0200, Sander Striker wrote:
I am well beyond 100% in support of the sms schema. The only
question is what is which, do we wrap the pool schema in sms,
or do 'pools' become sms?
Um. Hello? Have you counted the number of third party modules in
existence?
Tossing the pools means tossing the basic framework for a couple hundred
modules. apr_pool_t and apr_p* will remain (effectively) forever.
hiya greg,
you know that, i know that, we all know that, and so can cater
Greg's argument (and I'm leaning that way) says 'pools are now widely
deployed'.
Grow a pool into an sms, don't break anyone's code along the way (by making
the
default sms our beloved pool schema) and we are in strong shape.
yaaay :)
[btw, i'm sorry i got so stressed yesterday: seeing so
On Thu, Jun 07, 2001 at 09:27:00AM -0700, Justin Erenkrantz wrote:
On Thu, Jun 07, 2001 at 03:54:24PM +0200, Luke Kenneth Casson Leighton wrote:
only an SMS instance should know exactly how to deal with its
memory - _including_ locking - IF it is needed.
Ah. I see the logic in that.
Here is why I thought that:
David Reid wrote:
When we're done we'll have
locks - apr_sms_t
sms - locks - apr_sms_t
So personally I don't see the problem and thus I made the change! I guess
maybe it's because people keep saying that we're going to change the pools
to use sms.
On Thu, Jun 07, 2001 at 08:03:46AM -0700, [EMAIL PROTECTED] wrote:
As it happens, this is exactly what I envisioned when SMS was first
discussed. Namely, a new back-end for pools that can use any allocator.
ack. sorry for thinking otherwise.
luke
On Fri, Jun 08, 2001 at 02:45:09PM +0200, Luke Kenneth Casson Leighton wrote:
what i perhaps should recommend is that a series of independent
libraries be created.
e.g. libaprhttputil (i know it's a bit long).
Aaron Bannert and I were discussing that as well yesterday. Yeah, we
kind of get
- date/time manipulation.
at present, all i need to be able to do is get a
time_t and display it in a nice localtime format.
ripping code from httpd to do this is... uh.. silly?
Submit a patch and I'll commit it into apr. I think date and time stuff
should be yanked out into
On Fri, 8 Jun 2001, Luke Kenneth Casson Leighton wrote:
what i perhaps should recommend is that a series of independent
libraries be created.
e.g. libaprhttputil (i know it's a bit long).
why?
we don't link against libcstdio libcstring libcsyscalls libcsortnsearch
...
the point of a
On Fri, Jun 08, 2001 at 10:47:10AM -0700, dean gaudet wrote:
On Fri, 8 Jun 2001, Luke Kenneth Casson Leighton wrote:
what i perhaps should recommend is that a series of independent
libraries be created.
e.g. libaprhttputil (i know it's a bit long).
why?
we don't link against
On Fri, Jun 08, 2001 at 10:52:34AM -0700, Justin Erenkrantz wrote:
On Fri, Jun 08, 2001 at 10:47:10AM -0700, dean gaudet wrote:
On Fri, 8 Jun 2001, Luke Kenneth Casson Leighton wrote:
what i perhaps should recommend is that a series of independent
libraries be created.
e.g.
On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
We could implement pool using sms but we'd loose a great deal
of flexibility
and a great opportunity to make APR even more useful.
Pools are a single way of dealing with handing out memory. they imply a
degree of overhead
Bugger... wish I could avoid sending this to two lists, but I guess
it does overlap.
On Wed, Jun 06, 2001 at 01:04:29AM -0700, Greg Stein wrote:
On Tue, Jun 05, 2001 at 11:25:43PM -0400, Cliff Woolley wrote:
On Tue, 5 Jun 2001, Greg Stein wrote:
...
The basic problem with the current
24 matches
Mail list logo
