Date: Sat, 19 Jun 1999 15:13:18 -0700 (PDT)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@apache.org
cc: zeev@zend.com
Subject: Re: work in progress: mpm-3.tar.gz (fwd)
In-Reply-To: <Pine.WNT.4.10.9906191754210.-141409@helium.jetpen.com>
Message-ID: <Pine.LNX.3.96dg4.990619150429.27639W-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Sat, 19 Jun 1999, Rasmus Lerdorf wrote:

> > > Hrm, when I first read Dean's description, I thought about this too, but
> > > figured we wouldn't have a problem because we really just have a single
> > > entry point.  Our only other hook is the config stuff and we don't do
> > > anything that I think would require it to be done from the same thread.
> > > However, I could see this restriction being a pain if we wanted to be able
> > > to enter PHP from more that just the content-handling request phase.
> > > I would think this would be a big problem for mod_perl stuff.
> > 
> > It does affect us.  We change the configuration directives for the current
> > thread and expect them to take affect when the PHP callback is called;
> > Under these restrictions, we can't really do it.
> 
> Hrm..  True, and we store it TLS-style keyed on the thread id.  How the
> heck is it useful to have a module's init handler be in a separate thread
> from the actual invocation later on?  Well, ok, the answer was already
> given, and that is to use Apache's memory pool mechanism to store things.
> We can abstract that away in SAPI, I guess, but 3rd party things that
> don't know about Apache's memory management mechanism and do TLS-style
> things to be thread-safe are going to be confused.  So yes, I agree with
> you, it would be a PITA for us.

I really don't understand the difficulty.

I return to my earlier example:

    FILE *f = fopen("foo", "r");

You may now use f in any thread.  There's no requirement that f be used
only in the thread which created it.  I don't see why such a requirement
is necessary!  If libc didn't keep everything it needed to know in the
structure pointed to by f, why does it have a structure to begin with?

Now, you're complaining about TLS.  Apache knows nothing about TLS.
It won't know anything about it until that mythical portable run-time
appears.  It's not like I'm breaking anything, there's nothing to break.

As far as I understand your point, you're saying that there may exist
some library such that when you do:

    FILE *f = fopen("foo", "r");

it stuffs something into the TLS for the thread calling fopen.

Guys, that's dumb.  That's more complicated than it needs to be.

Now, if your complaint is:

    the dir_create/dir_merge methods don't include a conn_rec or
    request_rec when used at run-time

I'm with you all the way.  What you're saying is that for the
dir_create/dir_merge functions, when used at run time, you have no way
of knowing the context in which they're being used.  That we can fix.

Suppose that's fixed.  We can make this guarantee:

    whenever apache calls a module at run-time, it guarantees to pass
    it a conn_rec * in some form or another

Ok, so apache enters your module at entry point foo.  You do this:

    foo(conn_rec *c)
    {
	void *tls;

	tls = find_my_tls(c);
	set the tls for whatever thread library you're using = tls;
	do whatever foo() would have done in apache 1.x
    }

Your module really has no excuse, we're giving you a piece of context
(the conn_rec) which we guarantee to be the same for every phase of
the request.  Why do you need the thread to be the same?

I'm not interested in totally broken 3rd party libraries.  If you have
to deal with these then use an MPM that uses the same thread for all
phases.

Dean