[EMAIL PROTECTED] wrote:
> Hi,
>
> Sorry if this is a little off-topic....
That is not off-topic!
>
> I'm presentently trying to modifiy the mod_webapp source so that concurrent
> warp requests can be supported on NT. To do this, I'm implementing a pool
> of sockets per warp connection and each time a warp request is made a socket
> is acquired from the pool, used and then returned. This insures that only a
> single request is active on a socket at a time and so far the prototype I
> have is working and seems to address the problem.
Great! Could you send a diff -u of your changes?
>
> I've had a look at the apr documentation but it is pretty brief. I'm trying
> to get a proper understanding of how exactly the apr pool a.d.t. behaves and
> how memory is cleaned up with it.
>
> My understanding (so far) is that an apr pool essentially makes memory
> cleanup a bit easier by cleaning up all datastructures associated with it
> when it is destroyed. This removes the need to cleanup all datastructures
> individually and makes memory leaks less likely. As far as I can see the
> only way to cleanup a data structure associated with a pool is to free the
> entire pool. Is this correct? In this way, the pool does not behave like
> many common pool implementations which have alloc() and free() methods and
> are basically there to prevent memory allocation routine overhead.
The best place to look is the APR sources.
The pools are a tree structure that allows easy cleanups.
For example if you allocate something in the request pool you are sure that the
memory is "recycled" at the end of the request.
Typicaly use it:
int toto(apr_pool_t p)
{
apr_pool_t *sp;
apr_pool_create(&sp, p);
while (not finished) {
apr_pool_clear(sp); // the pool.
... // do what what you need with the sp pool.
}
apr_pool_destroy(sp); // free the memory.
}
The module that calls toto() could decide whether it needs to clean the pool or
not. Cleaning the p pool cleans the sp pool.
>
> If anyone could fill me in on more details or point me to some
> documentation, that would be great!
>
> Thanks Simon
>
> -- To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]> For additional commands,
> e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
