apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: Pools in threads
Date Sun, 15 Jul 2001 23:54:14 GMT
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

:)


Mime
View raw message