You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ruediger Pluem <rp...@apache.org> on 2008/10/28 22:31:41 UTC
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
On 10/28/2008 08:00 AM, pquerna@apache.org wrote:
> Author: pquerna
> Date: Tue Oct 28 00:00:15 2008
> New Revision: 708462
>
> URL: http://svn.apache.org/viewvc?rev=708462&view=rev
> Log:
> Add a work in progress, a completely new, "Simple MPM".
>
> Added:
> httpd/httpd/trunk/server/mpm/simple/ (with props)
Nitpicking: While event MPM is still in experimental simple is not? :-).
As for name proposals, how about
Generic MPM
Universal MPM
> Added: httpd/httpd/trunk/server/mpm/simple/simple_api.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/simple/simple_api.c?rev=708462&view=auto
> ==============================================================================
> +static const char*
> +set_proccount(cmd_parms *cmd, void *baton, const char *arg)
> +{
> + const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
> + if (err != NULL) {
> + return err;
> + }
> +
> + simple_core_get()->procmgr.proc_count = atoi(arg);
Does this work on ANSI compilers?
>
> Added: httpd/httpd/trunk/server/mpm/simple/simple_io.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/simple/simple_io.c?rev=708462&view=auto
> ==============================================================================
> --- httpd/httpd/trunk/server/mpm/simple/simple_io.c (added)
> +++ httpd/httpd/trunk/server/mpm/simple/simple_io.c Tue Oct 28 00:00:15 2008
> @@ -0,0 +1,279 @@
> +/* Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +#include "httpd.h"
> +#include "http_log.h"
> +#include "ap_listen.h"
> +#include "simple_types.h"
> +#include "simple_io.h"
> +#include "simple_event.h"
> +
> +#include "http_connection.h"
> +#include "util_filter.h"
> +#include "http_main.h"
> +#include "mpm.h"
> +#include "scoreboard.h"
> +#include "http_vhost.h"
> +
> +void
> +simple_io_timeot_cb(simple_core_t *sc,
I guess this should be simple_io_timeout_cb.
> + void *baton)
> +{
> + simple_conn_t *scon = (simple_conn_t *)baton;
> + /* pqXXXXX: handle timeouts. */
> + conn_rec *c = scon->c;
> + conn_state_t *cs = c->cs;
> +
> + cs = NULL;
> +
> + ap_log_error(APLOG_MARK, APLOG_WARNING, 0, ap_server_conf,
> + "io timeout hit (?)");
> +}
> +
> +static apr_status_t
> +simple_io_process(simple_conn_t *scon)
> +{
> + apr_status_t rv;
> +
> + if (scon->c->clogging_input_filters && !scon->c->aborted) {
> + /* Since we have an input filter which 'cloggs' the input stream,
> + * like mod_ssl, lets just do the normal read from input filters,
> + * like the Worker MPM does.
> + */
> + ap_run_process_connection(scon->c);
> + if (scon->c->cs->state != CONN_STATE_SUSPENDED) {
> + scon->c->cs->state = CONN_STATE_LINGER;
> + }
> + }
> +
> + simple_core_t *sc = scon->sc;
> + conn_rec *c = scon->c;
> + conn_state_t *cs = c->cs;
This does not work on ANSI C compilers. Declarations need to be at the start of the block.
> Added: httpd/httpd/trunk/server/mpm/simple/simple_event.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/simple/simple_event.c?rev=708462&view=auto
> ==============================================================================
> --- httpd/httpd/trunk/server/mpm/simple/simple_event.c (added)
> +++ httpd/httpd/trunk/server/mpm/simple/simple_event.c Tue Oct 28 00:00:15 2008
> @@ -0,0 +1,81 @@
> +/* Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +#define APR_RING_DEBUG 1
> +
> +#include "simple_types.h"
> +#include "simple_event.h"
> +
> +void
> +simple_register_timer(simple_core_t *sc,
> + simple_timer_cb cb,
> + void *baton,
> + apr_time_t relative_time)
> +{
> + simple_timer_t *elem = NULL;
> + simple_timer_t *ep = NULL;
> + int inserted = 0;
> + apr_time_t t = apr_time_now() + relative_time;
> +
> + apr_thread_mutex_lock(sc->mtx);
> +
> + APR_RING_CHECK_CONSISTENCY(&sc->timer_ring, simple_timer_t, link);
> + APR_RING_CHECK_CONSISTENCY(&sc->dead_timer_ring, simple_timer_t, link);
> +
> + if (!APR_RING_EMPTY(&sc->dead_timer_ring, simple_timer_t, link)) {
> + elem = APR_RING_FIRST(&sc->dead_timer_ring);
> + APR_RING_REMOVE(elem, link);
> + APR_RING_CHECK_CONSISTENCY(&sc->dead_timer_ring, simple_timer_t, link);
> + }
> + else {
> + elem = (simple_timer_t *) apr_pcalloc(sc->pool, sizeof(simple_timer_t));
> + }
> +
> + APR_RING_ELEM_INIT(elem, link);
> + elem->expires = t;
> + elem->cb = cb;
> + elem->baton = baton;
> +
> + APR_RING_CHECK_CONSISTENCY(&sc->timer_ring, simple_timer_t, link);
> +
> + /* pqXXXXXX: skiplist would be a nice optimization here. */
> + if (!APR_RING_EMPTY(&sc->timer_ring, simple_timer_t, link)) {
> + ep = APR_RING_FIRST(&sc->timer_ring);
> + while (inserted == 0 &&
> + ep != APR_RING_SENTINEL(&sc->timer_ring, simple_timer_t, link))
> + {
> + if (ep->expires < elem->expires) {
> + APR_RING_CHECK_CONSISTENCY(&sc->timer_ring, simple_timer_t, link);
Do we really need this check here? We have already done this.
> + APR_RING_INSERT_BEFORE(ep, elem, link);
> + inserted = 1;
> + APR_RING_CHECK_CONSISTENCY(&sc->timer_ring, simple_timer_t, link);
> + }
> + ep = APR_RING_NEXT(ep, link);
> + }
> + }
> +
> + APR_RING_CHECK_CONSISTENCY(&sc->timer_ring, simple_timer_t, link);
Do we really need this check here? We have already done this.
> +
> + if (!inserted) {
> + APR_RING_INSERT_TAIL(&sc->timer_ring,
> + elem, simple_timer_t, link);
> + }
> +
> + APR_RING_CHECK_CONSISTENCY(&sc->timer_ring, simple_timer_t, link);
> +
> + apr_thread_mutex_unlock(sc->mtx);
> +}
> +
Regards
Rüdiger
Re: Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by whiye_hust <wh...@163.com>.
发件人： Paul Querna
发送时间： 2008-10-29 07:17:45
收件人： dev
抄送：
主题： Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Paul Querna wrote:
> André Malo wrote:
>> * Paul Querna wrote:
>>
>>> Ruediger Pluem wrote:
>>
>>>> This does not work on ANSI C compilers. Declarations need to be at the
>>>> start of the block.
>>> Then lets not support them.
>>>
>>> C90 required that variable decls came before code, but IIRC C99 style
>>> mid-function declarations should work on pretty much all modern
>>> platforms, aka anything with GCC or MSVC.
>>
>> -1.
>> "IIRC" and "pretty much all modern" are both bad reasons for being
>> sloppy ;-)
>>
>> IIRC ( >:-> ) the AIX compiler actually doesn't like it, but other
>> people know that better.
>
> Then lets not support AIX :-)
To expand on my beliefs around this a little bit, if a platform doesn't
have things like kqueue, epool or event ports, and it still doesn't have
a c99 compiler, where is the value in supporting it, they are likely
still using Apache 1.3 anyways.
-Paul
^_^ I gree with you.
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> Takashi Sato wrote:
>> int main(){
>> puts("");
>> int a = 0;
>> return 0;
>> }
>>
>> does not compile with error C2143.
>
> thats lame.
>
> Can we just use c++ yet?
>
> Guess I'll go through all the code and fix this.
Especially considering the MS doesn't have a C compiler, they use the C++
engine as the base of their C language compiler (leading to many unusual
and irksome/convenient behaviors). Strange this isn't one of them.
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Paul Querna <ch...@force-elite.com>.
Takashi Sato wrote:
> On Tue, 28 Oct 2008 16:16:38 -0700
> Paul Querna <ch...@force-elite.com> wrote:
>
>> Paul Querna wrote:
>>> André Malo wrote:
>>>> * Paul Querna wrote:
>>>>
>>>>> Ruediger Pluem wrote:
>>>>>> This does not work on ANSI C compilers. Declarations need to be at the
>>>>>> start of the block.
>>>>> Then lets not support them.
>>>>>
>>>>> C90 required that variable decls came before code, but IIRC C99 style
>>>>> mid-function declarations should work on pretty much all modern
>>>>> platforms, aka anything with GCC or MSVC.
>>>> -1.
>>>> "IIRC" and "pretty much all modern" are both bad reasons for being
>>>> sloppy ;-)
>>>>
>>>> IIRC ( >:-> ) the AIX compiler actually doesn't like it, but other
>>>> people know that better.
>>> Then lets not support AIX :-)
>> To expand on my beliefs around this a little bit, if a platform doesn't
>> have things like kqueue, epool or event ports, and it still doesn't have
>> a c99 compiler, where is the value in supporting it, they are likely
>> still using Apache 1.3 anyways.
>>
>> -Paul
>>
>
> VC++2005 doesn't support mid-function declarations as a C compiler.
> Maybe VC++2008 doesn't either.
> With a file name extension ".c",
>
> #include <stdio.h>
> int main(){
> puts("");
> int a = 0;
> return 0;
> }
>
> does not compile with error C2143.
thats lame.
Can we just use c++ yet?
Guess I'll go through all the code and fix this.
Sigh,
-Paul
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./
simple/
Posted by Takashi Sato <ta...@lans-tv.com>.
On Tue, 28 Oct 2008 16:16:38 -0700
Paul Querna <ch...@force-elite.com> wrote:
> Paul Querna wrote:
> > André Malo wrote:
> >> * Paul Querna wrote:
> >>
> >>> Ruediger Pluem wrote:
> >>
> >>>> This does not work on ANSI C compilers. Declarations need to be at the
> >>>> start of the block.
> >>> Then lets not support them.
> >>>
> >>> C90 required that variable decls came before code, but IIRC C99 style
> >>> mid-function declarations should work on pretty much all modern
> >>> platforms, aka anything with GCC or MSVC.
> >>
> >> -1.
> >> "IIRC" and "pretty much all modern" are both bad reasons for being
> >> sloppy ;-)
> >>
> >> IIRC ( >:-> ) the AIX compiler actually doesn't like it, but other
> >> people know that better.
> >
> > Then lets not support AIX :-)
>
> To expand on my beliefs around this a little bit, if a platform doesn't
> have things like kqueue, epool or event ports, and it still doesn't have
> a c99 compiler, where is the value in supporting it, they are likely
> still using Apache 1.3 anyways.
>
> -Paul
>
VC++2005 doesn't support mid-function declarations as a C compiler.
Maybe VC++2008 doesn't either.
With a file name extension ".c",
#include <stdio.h>
int main(){
puts("");
int a = 0;
return 0;
}
does not compile with error C2143.
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
>
> FWIW, I don't believe in latest and greatest linux distro as a good
> measure, but I do believe that there are only a few platforms that we
> should make design decisions around:
> - Linux 2.6
> - FreeBSD 7
> - Solaris 10
> - Windows Vista
the last one, there are too many IT professionals who have a very
unfavorable opinion on Vista/2008 and will not be moving from 2003.
I'd suggest 2003 server as a baseline, with accedental support to 2000
server. But MS just recently acknowledged that 2003 addicts will not be
put out to pasture before having the opportunity to jump across to the
windows next OS. So 2003 is far from dead.
AW: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Graham Leggett
> Gesendet: Dienstag, 4. November 2008 18:21
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r708462 - in
> /httpd/httpd/trunk/server/mpm: ./ simple/
>
> Paul Querna wrote:
>
> > Its trunk, it better be unstable or we are doing something wrong.
> >
> > Thats why I think we should delete prefork, worker, event,
> threadpool,
> > perchild, and leader MPMs.
>
> Since when was instability a design goal of ours? :)
>
> When simple proves itself better than worker and prefork, +1
> to having
> them removed. But only when simple has proved itself better first.
+1 to this. New things have to prove themselves before we finally dump
older things.
Regards
Rüdiger
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Graham Leggett <mi...@sharp.fm>.
Paul Querna wrote:
> Its trunk, it better be unstable or we are doing something wrong.
>
> Thats why I think we should delete prefork, worker, event, threadpool,
> perchild, and leader MPMs.
Since when was instability a design goal of ours? :)
When simple proves itself better than worker and prefork, +1 to having
them removed. But only when simple has proved itself better first.
Regards,
Graham
--
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Nov 4, 2008, at 12:15 PM, Paul Querna wrote:
> Graham Leggett wrote:
>> Justin Erenkrantz wrote:
>>> I think MPMs are a design mis-feature. The fact that the same
>>> directive value can be (and is!) interpreted in non-uniform ways by
>>> different MPMs bugs me to no end. -- justin
>> That is a flaw in the MPMs themselves (overloading a term is evil I
>> agree), but not in the MPM concept as a whole.
>> The fact we have MPMs at all gives us the power to develop
>> something like the simple MPM alongside existing stable MPMs,
>> without being forced to endure a period of instability where the
>> server doesn't work at all.
>
> Its trunk, it better be unstable or we are doing something wrong.
>
> Thats why I think we should delete prefork, worker, event,
> threadpool, perchild, and leader MPMs.
>
Ummm... right now, trunk is the source for backports to
2.2.x.... Also, there are potential backports for these MPMs in
trunk that are not in 2.2.x.... So, if we decide, we either need
to branch off trunk to 2.2-dev and then delete, or branch off
trunk to httpd-nola and delete on *that* branch.
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Nick Kew <ni...@webthing.com>.
William A. Rowe, Jr. wrote:
> What about perchild? No answer, but removing it at this instant doesn't
> leave it glaring in our face that this problem set has not been solved.
Making unixd a module is the first step to removing the need for
perchild. It should cease to need an MPM, and work with a new
conventional module under arch/unix instead.
At least, that's the general idea.
--
Nick Kew
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> Graham Leggett wrote:
>> Justin Erenkrantz wrote:
>>
>>> I think MPMs are a design mis-feature. The fact that the same
>>> directive value can be (and is!) interpreted in non-uniform ways by
>>> different MPMs bugs me to no end. -- justin
>>
>> That is a flaw in the MPMs themselves (overloading a term is evil I
>> agree), but not in the MPM concept as a whole.
>>
>> The fact we have MPMs at all gives us the power to develop something
>> like the simple MPM alongside existing stable MPMs, without being
>> forced to endure a period of instability where the server doesn't work
>> at all.
+++1
> Its trunk, it better be unstable or we are doing something wrong.
Don't worry, if you accidentally commit some rock-solid code, we'll still
forgive you :)
> Thats why I think we should delete prefork, worker, event, threadpool,
> perchild, and leader MPMs.
-1 to worker, prefork. As far as event, leader, threadpool, they seem to
be proofs of concept realized in Simple (yes? no?) and should be svn rm'ed.
What about perchild? No answer, but removing it at this instant doesn't
leave it glaring in our face that this problem set has not been solved.
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Paul Querna <ch...@force-elite.com>.
Graham Leggett wrote:
> Justin Erenkrantz wrote:
>
>> I think MPMs are a design mis-feature. The fact that the same
>> directive value can be (and is!) interpreted in non-uniform ways by
>> different MPMs bugs me to no end. -- justin
>
> That is a flaw in the MPMs themselves (overloading a term is evil I
> agree), but not in the MPM concept as a whole.
>
> The fact we have MPMs at all gives us the power to develop something
> like the simple MPM alongside existing stable MPMs, without being forced
> to endure a period of instability where the server doesn't work at all.
Its trunk, it better be unstable or we are doing something wrong.
Thats why I think we should delete prefork, worker, event, threadpool,
perchild, and leader MPMs.
Thanks,
-Paul
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Graham Leggett <mi...@sharp.fm>.
Justin Erenkrantz wrote:
> I think MPMs are a design mis-feature. The fact that the same
> directive value can be (and is!) interpreted in non-uniform ways by
> different MPMs bugs me to no end. -- justin
That is a flaw in the MPMs themselves (overloading a term is evil I
agree), but not in the MPM concept as a whole.
The fact we have MPMs at all gives us the power to develop something
like the simple MPM alongside existing stable MPMs, without being forced
to endure a period of instability where the server doesn't work at all.
It also allows us to support newer OS features on modern systems,
without being forced to ignore those features because legacy platform X
doesn't support it. Legacy platform X can carry on using prefork (or
whatever).
Regards,
Graham
--
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Nov 3, 2008 at 11:23 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> You miss my point. If we just have one MPM, and make it
> such that other MPMs are at a significant advantage, then
> why even have MPMs? Hardcode in simple and be done.
(Assume you may have meant 'disadvantage'?)
> In any case, we can pretty much do that with Worker now,
> as well as Simple...
I think MPMs are a design mis-feature. The fact that the same
directive value can be (and is!) interpreted in non-uniform ways by
different MPMs bugs me to no end. -- justin
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Nov 2, 2008, at 1:04 PM, Justin Erenkrantz wrote:
> On Thu, Oct 30, 2008 at 6:06 AM, Jim Jagielski <ji...@jagunet.com>
> wrote:
>> I tend to agree... as long as the architectural design doesn't
>> prevent people from creating (or keeping) MPMs, then this is all
>> good. Believe it or not, as people on the front-lines of handling
>> Apache setup and support for organizations can attest to, MPMs are a
>> valued feature.
>
> I disagree. It's incredibly confusing to have compile-time
> definitions and inability to adjust them at run-time.
>
> I'd prefer that we remove all MPMs and teach whatever remains to be
> able to emulate prefork (multiple-process/single-thread) or worker
> (multiple-process/multiple-thread) at run-time.
>
You miss my point. If we just have one MPM, and make it
such that other MPMs are at a significant advantage, then
why even have MPMs? Hardcode in simple and be done.
In any case, we can pretty much do that with Worker now,
as well as Simple...
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
>
>> We aren't there. I don't care about prefork, if it isn't threaded there
>> is no point, but simple isn't the answer. Because it's a static pool
>> of threads, it's no different than win32, but win32 really screams for
>> a resizeable thread pool for developer's installations and such (varies
>> between very small footprint and a modest number of connections).
>
> Then improve the threadpool code in apr-util, the simple mpm itself has
> very little to do with the thread pooling implementation:
You miss my point though. Sure - we can invest 100% effort into simple,
and within months demonstrate that all other mpms are inferior. At that
point we deprecate and make 'simple' the default. Next release, svn rm
those ancient sources. Great!
It just doesn't seem to be worth forcing this unless there is a measurable
benefit to cutting out or rearranging the mpm hooks. And if there is, then
maybe they just need refactoring (?)
I'm all over the idea of calling all old mpm's retired. Just didn't see a
reason to svn rm the code until 'simple' is proven in the wild.
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
> Justin Erenkrantz wrote:
>> I'd prefer that we remove all MPMs and teach whatever remains to be
>> able to emulate prefork (multiple-process/single-thread) or worker
>> (multiple-process/multiple-thread) at run-time.
>
> I suspect we are still a ways away from this. If we can make the point
> that there's a obvious one-and-only mpm, then yes, maybe it's time.
On unix, I think we are much closer than you think:
SimpleThreadCount 1
SimpleProcCount 200
Would behave very similar to prefork does today. (and we can make some
further optimizations when threadCount == 1, but those are optimizations
to be done later imo).
> We aren't there. I don't care about prefork, if it isn't threaded there
> is no point, but simple isn't the answer. Because it's a static pool
> of threads, it's no different than win32, but win32 really screams for
> a resizeable thread pool for developer's installations and such (varies
> between very small footprint and a modest number of connections).
Then improve the threadpool code in apr-util, the simple mpm itself has
very little to do with the thread pooling implementation:
http://apr.apache.org/docs/apr-util/1.3/group___a_p_r___util___t_p.html
It has the start number and can spawn more -- but I don't think it
actively reaps idle threads.
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
>
> I'd prefer that we remove all MPMs and teach whatever remains to be
> able to emulate prefork (multiple-process/single-thread) or worker
> (multiple-process/multiple-thread) at run-time.
I suspect we are still a ways away from this. If we can make the point
that there's a obvious one-and-only mpm, then yes, maybe it's time.
We aren't there. I don't care about prefork, if it isn't threaded there
is no point, but simple isn't the answer. Because it's a static pool
of threads, it's no different than win32, but win32 really screams for
a resizeable thread pool for developer's installations and such (varies
between very small footprint and a modest number of connections).
We'll truly stall if we begin the "one right mpm" war. What we can do
is to make the mpm itself fairly innocuous, and move out some stuff from
the mpm to modules or core (e.g. like the new arch/unix/mod_unixd!!!)
That is measureable progress :)
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Oct 30, 2008 at 6:06 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> I tend to agree... as long as the architectural design doesn't
> prevent people from creating (or keeping) MPMs, then this is all
> good. Believe it or not, as people on the front-lines of handling
> Apache setup and support for organizations can attest to, MPMs are a
> valued feature.
I disagree. It's incredibly confusing to have compile-time
definitions and inability to adjust them at run-time.
I'd prefer that we remove all MPMs and teach whatever remains to be
able to emulate prefork (multiple-process/single-thread) or worker
(multiple-process/multiple-thread) at run-time.
My $.02. -- justin
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Oct 29, 2008, at 5:04 PM, Graham Leggett wrote:
> Paul Querna wrote:
>
>> FWIW, I don't believe in latest and greatest linux distro as a good
>> measure, but I do believe that there are only a few platforms that
>> we should make design decisions around:
>> - Linux 2.6
>> - FreeBSD 7
>> - Solaris 10
>> - Windows Vista
>> If something is *fast* or *good* and can be done on all of the
>> above platforms, I would argue we should do it from a design
>> perspective, and I'm very much opposed to limiting how we design
>> stuff based on the constraints of other less popular operating
>> systems, cf epoll/kqueue/event ports.
>
> I think we shouldn't forget that we have MPMs - if we need to
> support a non mainstream platform, at the very least make sure that
> at least one functional and acceptable alternative MPM exists for
> that platform.
>
I tend to agree... as long as the architectural design doesn't
prevent people from creating (or keeping) MPMs, then this is all
good. Believe it or not, as people on the front-lines of handling
Apache setup and support for organizations can attest to, MPMs are a
valued feature.
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Graham Leggett <mi...@sharp.fm>.
Paul Querna wrote:
> FWIW, I don't believe in latest and greatest linux distro as a good
> measure, but I do believe that there are only a few platforms that we
> should make design decisions around:
> - Linux 2.6
> - FreeBSD 7
> - Solaris 10
> - Windows Vista
>
> If something is *fast* or *good* and can be done on all of the above
> platforms, I would argue we should do it from a design perspective, and
> I'm very much opposed to limiting how we design stuff based on the
> constraints of other less popular operating systems, cf
> epoll/kqueue/event ports.
I think we shouldn't forget that we have MPMs - if we need to support a
non mainstream platform, at the very least make sure that at least one
functional and acceptable alternative MPM exists for that platform.
Many of the "obscure" platforms can be potentially be embedded devices,
that see far greater but ultimately invisible deployment than the
"traditional" public facing webserver does.
Regards,
Graham
--
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Paul Querna <ch...@force-elite.com>.
Niklas Edmundsson wrote:
> Feels like we're going from "lets be portable" to "if it's not the
> latest&greatest linux-distro that I use lets drop it". Sounds like a bad
> decision to me.
...
> And lets continue being portable, please.
FWIW, I don't believe in latest and greatest linux distro as a good
measure, but I do believe that there are only a few platforms that we
should make design decisions around:
- Linux 2.6
- FreeBSD 7
- Solaris 10
- Windows Vista
If something is *fast* or *good* and can be done on all of the above
platforms, I would argue we should do it from a design perspective, and
I'm very much opposed to limiting how we design stuff based on the
constraints of other less popular operating systems, cf
epoll/kqueue/event ports.
-Paul
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./
simple/
Posted by Niklas Edmundsson <ni...@acc.umu.se>.
On Tue, 28 Oct 2008, Paul Querna wrote:
>>> -1.
>>> "IIRC" and "pretty much all modern" are both bad reasons for being sloppy
>>> ;-)
>>>
>>> IIRC ( >:-> ) the AIX compiler actually doesn't like it, but other people
>>> know that better.
>>
>> Then lets not support AIX :-)
>
> To expand on my beliefs around this a little bit, if a platform doesn't have
> things like kqueue, epool or event ports, and it still doesn't have a c99
> compiler, where is the value in supporting it, they are likely still using
> Apache 1.3 anyways.
Feels like we're going from "lets be portable" to "if it's not the
latest&greatest linux-distro that I use lets drop it". Sounds like a
bad decision to me.
For the record, Takashis example compiles with a recent AIX compiler
(VAC 9) when using cc, xlc, and c99.
I'm for avoiding c99 for a while though, there are still a lot of c99
related bugs that show up in different compilers, and I don't really
thing we can gain that much by jumping on the c99 bandwagon.
And lets continue being portable, please.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@acc.umu.se
---------------------------------------------------------------------------
It's better to be rich and healthy than poor and sick
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Paul Querna <ch...@force-elite.com>.
Paul Querna wrote:
> André Malo wrote:
>> * Paul Querna wrote:
>>
>>> Ruediger Pluem wrote:
>>
>>>> This does not work on ANSI C compilers. Declarations need to be at the
>>>> start of the block.
>>> Then lets not support them.
>>>
>>> C90 required that variable decls came before code, but IIRC C99 style
>>> mid-function declarations should work on pretty much all modern
>>> platforms, aka anything with GCC or MSVC.
>>
>> -1.
>> "IIRC" and "pretty much all modern" are both bad reasons for being
>> sloppy ;-)
>>
>> IIRC ( >:-> ) the AIX compiler actually doesn't like it, but other
>> people know that better.
>
> Then lets not support AIX :-)
To expand on my beliefs around this a little bit, if a platform doesn't
have things like kqueue, epool or event ports, and it still doesn't have
a c99 compiler, where is the value in supporting it, they are likely
still using Apache 1.3 anyways.
-Paul
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Paul Querna <ch...@force-elite.com>.
André Malo wrote:
> * Paul Querna wrote:
>
>> Ruediger Pluem wrote:
>
>>> This does not work on ANSI C compilers. Declarations need to be at the
>>> start of the block.
>> Then lets not support them.
>>
>> C90 required that variable decls came before code, but IIRC C99 style
>> mid-function declarations should work on pretty much all modern
>> platforms, aka anything with GCC or MSVC.
>
> -1.
> "IIRC" and "pretty much all modern" are both bad reasons for being
> sloppy ;-)
>
> IIRC ( >:-> ) the AIX compiler actually doesn't like it, but other people
> know that better.
Then lets not support AIX :-)
Paul
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by André Malo <nd...@perlig.de>.
* Paul Querna wrote:
> Ruediger Pluem wrote:
> > This does not work on ANSI C compilers. Declarations need to be at the
> > start of the block.
>
> Then lets not support them.
>
> C90 required that variable decls came before code, but IIRC C99 style
> mid-function declarations should work on pretty much all modern
> platforms, aka anything with GCC or MSVC.
-1.
"IIRC" and "pretty much all modern" are both bad reasons for being
sloppy ;-)
IIRC ( >:-> ) the AIX compiler actually doesn't like it, but other people
know that better.
nd
--
> Rätselnd, was ein Anthroposoph mit Unterwerfung zu tun hat...
^^^^^^^^^^^^
[...] Dieses Wort gibt so viele Stellen für einen Spelling Flame her, und
Du gönnst einem keine einzige. -- Jean Claude und David Kastrup in dtl
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Posted by Paul Querna <ch...@force-elite.com>.
Ruediger Pluem wrote:
>
> On 10/28/2008 08:00 AM, pquerna@apache.org wrote:
>> Author: pquerna
>> Date: Tue Oct 28 00:00:15 2008
>> New Revision: 708462
>>
>> URL: http://svn.apache.org/viewvc?rev=708462&view=rev
>> Log:
>> Add a work in progress, a completely new, "Simple MPM".
>>
>> Added:
>> httpd/httpd/trunk/server/mpm/simple/ (with props)
>
> Nitpicking: While event MPM is still in experimental simple is not? :-).
I think the whole 'experimental' MPM thing should go away. If its in a
stable released version, it should be stable, not experimental.... But
thats a different thread.
Anyways, I would support moving Event out, since we have had the
clogging input filters / mod_ssl support in there for awhile :-)
> As for name proposals, how about
>
> Generic MPM
> Universal MPM
>
>
>> Added: httpd/httpd/trunk/server/mpm/simple/simple_api.c
>> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/simple/simple_api.c?rev=708462&view=auto
>> ==============================================================================
>
>> +static const char*
>> +set_proccount(cmd_parms *cmd, void *baton, const char *arg)
>> +{
>> + const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
>> + if (err != NULL) {
>> + return err;
>> + }
>> +
>> + simple_core_get()->procmgr.proc_count = atoi(arg);
>
> Does this work on ANSI compilers?
Doubtful.
>> + simple_core_t *sc = scon->sc;
>> + conn_rec *c = scon->c;
>> + conn_state_t *cs = c->cs;
>
> This does not work on ANSI C compilers. Declarations need to be at the start of the block.
Then lets not support them.
C90 required that variable decls came before code, but IIRC C99 style
mid-function declarations should work on pretty much all modern
platforms, aka anything with GCC or MSVC.
>> + APR_RING_CHECK_CONSISTENCY(&sc->timer_ring, simple_timer_t, link);
>
> Do we really need this check here? We have already done this.
>
>> + APR_RING_CHECK_CONSISTENCY(&sc->timer_ring, simple_timer_t, link);
>
> Do we really need this check here? We have already done this.
Ring Consistency Checks are no-ops unless APR_RING_DEBUG is defined, so,
all of these lines compile out unless you are hunting down a place you
are corrupting the ring.
I don't view them as important to remove, mostly because I was chasing
down a bug where I corrupted the timer_ring earlier in the evening.
> Regards
>
> Rüdiger
Thanks for reviewing,
Paul