Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of paul@querna.org designates
 209.85.210.198 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4A5341E7.9080801@sharp.fm>
References: <4239a4320907062220k21987b38uebbd3e7b1c7f0f37@mail.gmail.com>
	 <4A5332CD.5050101@sharp.fm>
	 <4239a4320907070514q286b87bbx2646ed5fb7e279ab@mail.gmail.com>
	 <4A5341E7.9080801@sharp.fm>
Date: Tue, 7 Jul 2009 09:39:42 -0400
Message-ID: <4239a4320907070639xf953b6u4905514e98c0dee8@mail.gmail.com>
Subject: Re: Events, Destruction and Locking
From: Paul Querna <paul@querna.org>
To: dev@httpd.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On Tue, Jul 7, 2009 at 8:39 AM, Graham Leggett<minfrin@sharp.fm> wrote:
> Paul Querna wrote:
>
>> Nah, 90% of what is done in moduels today should be out of process aka
>> in FastCGI.... or another method, but out of process. (regardless of
>> MPM)
>
> You're just moving the problem from one server to another, the problem
> remains unsolved. Whether the code runs within httpd space, or fastcgi
> space, the code still needs to run, and if it's written badly, the code
> will still leak/crash, and you still have to cater for it.

Yes, but in a separate process it has fault isolation.. and we can
restart it when it fails, neither of which are true for modules using
the in-process API directly -- look at the reliability of QMail, or
the newer architecture of Google's Chrome, they are both great
examples of fault isolation.