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]>
