On Fri, 7 Dec 2001, GOMEZ Henri wrote:
The pool_open, etc will be removed - same for the buf[] based
allocation.
why not. Frankly you love too much java :)
I just like simple things.
Stack-allocating buffers and then creating ( stack-allocated ) jk_pools
in the buffer is not that simple, and making it work with apr_pools was
extremely difficult ( or at least I couldn't figure any decent way ).
However, I'm not an C expert ( or even a C programmer ) - if
I'm missing
something please let me know.
free must match malloc, that's all for now :=)
Question could be about recycling pools.
That's simple - we do recycle the endpoint ( to preserve the open
connection ). So we don't need to malloc/free its pool on each request,
only when we connect and free.
It seems malloc is considered expensive ( it requires some sync in
mutithreaded environment ) - it's not that bad as in java, but still it's
easier to keep the block allocated.
PS: Costin, you go too fast, I didn't recognize anything in jk2 ;)
Is it that bad ?
I'm almost done - the only big change I'll do is finally abstract the
message handler ( but that'll be similar with what we have on the java
side ).
The only important thing that changed so far was data structures - and
it's mostly making public what was private in ajp/mod_jk/lb - in order to
make it easier to manage and give config handlers control, and to be able
to use it in jni and other workers as well.
I also added virtual methods, so apr pools and apache logger can be used.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]