On Sun, Jul 15, 2001 at 04:43:37PM -0700, Justin Erenkrantz wrote: > On Mon, Jul 16, 2001 at 12:46:31AM +0200, Luke Kenneth Casson Leighton wrote: > > > 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? > > I'm not sure I'm following you. The thread SMS never needs locks. i am not necessarily referring to locks.
if there is something _ever_ so slightly different about the circumstances under which sms instances need to be used, then what i am suggesting is that instead of doing this: apr_sms_general_t apr_sms_thread_capable_general_t [which was what you were recommending ;)] apr_sms_trivial_t apr_sms_thread_capable_trivial_t instead having a: apr_sms_thread_wrapping_redirector_t and use *that* to do the thread-capable-very-specific-things that i suspect you will need to do for all-and-any SMSes, pretty much, and that might not necessarily be locking, which simplifies the coding needed. > Sander was under the assumption that the parent of a thread can clean up > a thread. That isn't supported with POSIX pthreads (cleanly). > Apparently, Win32 has some support for this. This lack basically kills > off the parent/child relationship between SMSes across threads. ah, yes, but it _is_ supported by DCEthreads - see http://sourceforge.net/projects/freedce which provides, horror-of-horrors, thread cancellation *emulated* on top of POSIX threads. DCEthreads is an implementation of POSIX (draft 4) threads which of course drastically changed from the final release. now, if you examine Windows NT threads, i _bet_ they support thread cancellation properly, because they do support thread cancellation via dce/rpc (and dcom, which is basically an object-orientated interface on top of dce/rpc). why? because, well, that's a long story. also, take a lok at www.opengroup.org/dce, download the 88mb of the dce 1.22 source code, unpack it to its 430mb uncompressed size [no, i'm not kidding: yes, that's right, four hundred and thirty megabytes - 3.5 million lines of code, i had to use xargs to do wc on them], and you will find that there is DCEthreads supported for AIX, HP/UX, Solaris, DG/UX, SGI's Unix (forgotten what it is! IRIX *duh* :) ... but what i am basically saying is, on NT and Unix, thread cancellation _is_ possible, it's just that i think you might not be too happy about the coding-route you might have to take to _do_ it :) :) > pthread_cancel() gets us into all sorts of problems we don't want to > deal with. It has been discussed years ago between Ryan, Dean and > Manoj - see around 08-1999 - "First in a long line of APR related > patches". And, it isn't guaranteed to work, either (mutex acquires > are *not* interruptable). In that same thread, Ryan also brings up a > precursor to SMS. Rather interesting thread, really. (See > www.apachelabs.org if you don't have a favorite new-httpd archive.) > > Unless you have a clean way of killing off a thread from a parent, > thread-based SMS must be directly parented from a basic non-locking > SMS (like std SMS). > > I'm open to any creative suggestions that work. I'm just not aware > of any that work. -- justin :)
