Hi, I've done most of the changes suggested but am a little confused on a few points:
warp_socket_pool current has the following features: 1) It implements a socket pool. 2) The implementation is thread-safe (I think!) 3) The implementation uses atomics. In a mt environment all features except 3 are completely necessary. Should I add a new define WARP_USE_ATOMICS, or similar, which by default is defined? Now, in a st environment none of the above features are necessary, although, if 1) isn't supported then the name is probably a bit misleading! Which features, if any, should I take out for a st environment? Possible options: * Set the pool size to 1. (#define MAX_SOCKET_POOL_SIZE 1) * Remove the mutex locking. * Change the implementation so that a handle to a single socket is held. * Replace use of atomics with ints etc.. I've added the warp_sockpool_destroy function. As far I can tell I shouldn't add a call to it anywhere in the code, should I? Any thoughts? Thanks Simon Pier Fumagalli <[EMAIL PROTECTED]> wrote: > > "Jean-frederic Clere" <[EMAIL PROTECTED]> wrote: > > > atomic are very good but only used in mod_cache (experimental) and there > > the code is like: > > +++ > > #ifdef USE_ATOMICS > > apr_atomic_set(&obj->refcount, 1); > > #else > > obj->refcount = 1; > > #endif > > > > +++ > > That will be nice to do the same in mod_webapp (At least #ifdef > > APR_HAS_THREADS). > > Hmm.. We could define a couple of macros... > > > In lib/pr_warp.c: > > apr_socket_t * sock = 0; > > That is better to have > > apr_socket_t * sock = NULL; > > Yup... > > > Having a pool of size one when no threads probably saves a lot of > > #define APR_HAS_THREADS. > > Agreed... Or we can comment out large chunks of code... > > > Some changes in pr_warp_socketpool.c are needed ;-). > > Like what? BTW, can we keep this on the list? I won > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
