You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Howard Fear <hs...@pooh.pageplus.com> on 1996/08/04 04:36:14 UTC
Re: Win32 Progress Report
rasmus@madhaus.utcs.utoronto.ca writes:
> A lot of the add-on modules for Apache will break extremely badly in a
> true pre-emptive threading model. I am not sure how popular such a server
> will be if people can't use all the nifty modules.
Yes, but threading is probably inevitable. What's really needed is:
1) good documentation on how to write modules for the threaded
environment, do's and don'ts, etc.
2) Simple, well documented, interfaces for utility functions.
Both should be advertised available well before the release of the
threaded server so that module developers can get their modules in sync.
A developer's release is probably in order. And for those that don't,
treat it like any other public domain software - if its useful enough
someone will step forward and do it.
I'd be most concerned about the bigger modules, mod_php, mod_perl,
mod_rewrite, and so on. But all those people are active on this list,
so they should be available.
--
Howard Fear email1: howard_fear@pageplus.com
email2: howard_fear@stortek.com
http://www.pageplus.com/~hsf/
Re: Win32 Progress Report
Posted by Alexei Kosut <ak...@organic.com>.
On Mon, 5 Aug 1996 rasmus@madhaus.utcs.utoronto.ca wrote:
> > RST MT
> >
> > The server stops responding to The server only has one request
> > other requests whilst executing executing unsafe code at any one
> > the unsafe code. time.
>
> All I was saying was that it is easier to block a thread from executing
> an unsafe library call in rstthreads than it is in pre-emptive MT.
Not really. In POSIX threads, for example, all you need to do is the
following:
1. Declare somewhere:
static mutex_t my_mutex;
2. Before calling this unsafe library call, say:
mutex_lock(&my_mutex);
3. After calling the unsafe library call, say:
mutex_unlock(&my_mutex);
Should work like a charm. The one problem is if, for example, two
different modules both wanted to call the same function; they'd have to
agree to use the same mutex, otherwise they could both call the function
in different threads at the same time.
-- Alexei Kosut <ak...@organic.com> The Apache HTTP Server
http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
Re: Win32 Progress Report
Posted by ra...@madhaus.utcs.utoronto.ca.
> RST MT
>
> The server stops responding to The server only has one request
> other requests whilst executing executing unsafe code at any one
> the unsafe code. time.
All I was saying was that it is easier to block a thread from executing
an unsafe library call in rstthreads than it is in pre-emptive MT.
-Rasmus
Re: Win32 Progress Report
Posted by David Robinson <dr...@esi.co.uk>.
On Sun, 4 Aug 1996 rasmus@madhaus.utcs.utoronto.ca wrote:
> > rasmus@madhaus.utcs.utoronto.ca writes:
> > > A lot of the add-on modules for Apache will break extremely badly in a
> > > true pre-emptive threading model. I am not sure how popular such a
> > > server will be if people can't use all the nifty modules.
>...
>
> I am definitely not arguing against a threaded version. I just like
> RST's approach which gives you most of the benefits of a multi-threaded
> architecture without making it completely pre-emptive. A fully pre-emptive
> server, although technically elegant, makes it *extremely* difficult for
> programmers to write components for the server.
>
> > I'd be most concerned about the bigger modules, mod_php, mod_perl,
> > mod_rewrite, and so on. But all those people are active on this list,
> > so they should be available.
>
> I can make mod_php work nicely with RST's threads, but it would not be
> easy to make a pre-emptively threaded version. And not just because of
> the mod_php code. The various libraries that mod_php relies on like
> libmsql.a and libpq.a are not thread-safe. I would have to build some
> mechanism for preventing a pre-emptive threading server from having two
> threads inside these libraries at the same time. This can be done, sure,
> but it is certainly non-trivial.
This sounds very dubious to me. You are saying that many modules work
fine with non-pre-emptive threads, but not with pre-emptive MT? As as
pre-emptive system has a superset of the functionality of a non-pre-emptive
system, this cannot be true. And it is only a little harder to write
code for a pre-emptive system (definitely not '*extremely* difficult').
Here are the various levels of functionality that are possible with
the two types of server for 'difficult' modules. I will call the
non-pre-emptive server 'RST' and the pre-emptive server 'MT'.
1. A non-threads aware module 'A' is used. (Not at all re-entrant; the
programmer was unaware of threading issues.)
RST MT
The server may stop responding to The server stops responding to
other requests whilst executing other requests for the same module
the module code. The server stops whilst processing this request.
responding to other requests for
this module whilst processing this
request.
2. A re-entrant module, but which uses unsafe libraries. (The programmer
simply puts mutexes around the unsafe system calls for the MT version.
For the RST version, he explicitly yields control during any slow
operation.)
RST MT
The server stops responding to The server only has one request
other requests whilst executing executing unsafe code at any one
the unsafe code. time.
3. For completely MT-safe modules, both systems have the same functionality.
David.
Re: Win32 Progress Report
Posted by ra...@madhaus.utcs.utoronto.ca.
> rasmus@madhaus.utcs.utoronto.ca writes:
> > A lot of the add-on modules for Apache will break extremely badly in a
> > true pre-emptive threading model. I am not sure how popular such a
> > server will be if people can't use all the nifty modules.
>
> Yes, but threading is probably inevitable. What's really needed is:
> 1) good documentation on how to write modules for the threaded
> environment, do's and don'ts, etc.
> 2) Simple, well documented, interfaces for utility functions.
I am definitely not arguing against a threaded version. I just like
RST's approach which gives you most of the benefits of a multi-threaded
architecture without making it completely pre-emptive. A fully pre-emptive
server, although technically elegant, makes it *extremely* difficult for
programmers to write components for the server.
> I'd be most concerned about the bigger modules, mod_php, mod_perl,
> mod_rewrite, and so on. But all those people are active on this list,
> so they should be available.
I can make mod_php work nicely with RST's threads, but it would not be
easy to make a pre-emptively threaded version. And not just because of
the mod_php code. The various libraries that mod_php relies on like
libmsql.a and libpq.a are not thread-safe. I would have to build some
mechanism for preventing a pre-emptive threading server from having two
threads inside these libraries at the same time. This can be done, sure,
but it is certainly non-trivial.
-Rasmus