> In order to provide a win against the current pool code in a threaded > MPM, we *need* to have thread-specific SMS that have no locks or > association to anything other than a simple unlocked (from APR's > perspective) malloc/free (aka std) SMS. -- justin
okay. well... uhmmm... this is going to sound odd. i'm not even sure if it will help, because i am a bit out of my depth in understanding the problem. how about a 'pass-through' sms for threads? all it does is to create an apr_sms_thread_passthrough() is: memcpy(&thr_pthru, &someothersms_api); then OVERRIDE the create function, calling the *someothersms*->create. you then do your 'thread-specific' stuff that you need to do, e.g. locking _whatever_, i really don't know, as a wrapper around the someothersms. in other words, via this technique, you can turn a non-thread-capable SMS into a thread-safe one. ... does that sound a bit mad, but useful, or am i way off the mark. luke
