You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Hyde <bh...@pobox.com> on 1998/10/01 20:20:44 UTC
Removing ap_dummy_mutex from API
This removes the global ap_dummy_mutex used in multithread.h
as so:
-#define ap_create_mutex(name) ((mutex *)ap_dummy_mutex)
+#define ap_create_mutex(name) ((mutex *)-1)
It is currently defined in http_main.c
-/* this just need to be anything non-NULL */
-void *ap_dummy_mutex = &ap_dummy_mutex;
It's one of the four things that keeps one from using alloc.c
buff.c, and ap/ standalone.
It does change the API for unix only. You'll need to loadable modules
which use mutex. So I bumped the MODULE_MAGIC_NUMBER_MINOR.
Any complaints?
- ben hyde
---
Index: CHANGES
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/CHANGES,v
retrieving revision 1.1085
diff -u -r1.1085 CHANGES
--- CHANGES 1998/10/01 04:53:22 1.1085
+++ CHANGES 1998/10/01 18:19:48
@@ -1,5 +1,9 @@
Changes with Apache 1.3.3
+ *) Remove the global ap_dummy_mutex from the API. Increment
+ MODULE_MAGIC_NUMBER_MINOR, unix users will need to recompile
+ dynamicly loaded modules. [Ben Hyde]
+
*) Win32 name canonicalisation could end up using the server's
working directory to fill in some blanks. [Ken Parzygnat
<kp...@raleigh.ibm.com>] PR#3001
Index: include/ap_compat.h
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/include/ap_compat.h,v
retrieving revision 1.14
diff -u -r1.14 ap_compat.h
--- ap_compat.h 1998/07/13 11:32:33 1.14
+++ ap_compat.h 1998/10/01 18:19:48
@@ -112,7 +112,6 @@
#define die ap_die
#define discard_request_body ap_discard_request_body
#define document_root ap_document_root
-#define dummy_mutex ap_dummy_mutex
#define each_byterange ap_each_byterange
#define error_log2stderr ap_error_log2stderr
#define escape_html ap_escape_html
Index: include/ap_mmn.h
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/include/ap_mmn.h,v
retrieving revision 1.8
diff -u -r1.8 ap_mmn.h
--- ap_mmn.h 1998/09/17 20:23:41 1.8
+++ ap_mmn.h 1998/10/01 18:19:48
@@ -183,7 +183,7 @@
#ifndef MODULE_MAGIC_NUMBER_MAJOR
#define MODULE_MAGIC_NUMBER_MAJOR 19980917
#endif
-#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */
+#define MODULE_MAGIC_NUMBER_MINOR 1 /* 0...n */
#define MODULE_MAGIC_NUMBER MODULE_MAGIC_NUMBER_MAJOR /* backward compat */
/* Useful for testing for features. */
Index: include/multithread.h
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/include/multithread.h,v
retrieving revision 1.11
diff -u -r1.11 multithread.h
--- multithread.h 1998/05/03 17:31:10 1.11
+++ multithread.h 1998/10/01 18:19:48
@@ -49,9 +49,8 @@
#define APACHE_TLS
/* Only define the ones actually used, for now */
-extern void *ap_dummy_mutex;
-#define ap_create_mutex(name) ((mutex *)ap_dummy_mutex)
+#define ap_create_mutex(name) ((mutex *)-1)
#define ap_acquire_mutex(mutex_id) ((int)MULTI_OK)
#define ap_release_mutex(mutex_id) ((int)MULTI_OK)
#define ap_destroy_mutex(mutex_id) (0)
Index: main/http_main.c
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/main/http_main.c,v
retrieving revision 1.397
diff -u -r1.397 http_main.c
--- http_main.c 1998/09/21 10:16:11 1.397
+++ http_main.c 1998/10/01 18:19:49
@@ -215,10 +215,6 @@
#define MONCONTROL(x)
#endif
-#ifndef MULTITHREAD
-/* this just need to be anything non-NULL */
-void *ap_dummy_mutex = &ap_dummy_mutex;
-#endif
/*
* Actual definitions of config globals... here because this is
Index: support/httpd.exp
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/support/httpd.exp,v
retrieving revision 1.5
diff -u -r1.5 httpd.exp
--- httpd.exp 1998/09/01 20:21:14 1.5
+++ httpd.exp 1998/10/01 18:19:52
@@ -87,7 +87,6 @@
ap_die
ap_discard_request_body
ap_document_root
-ap_dummy_mutex
ap_each_byterange
ap_error_log2stderr
ap_escape_html
Index: test/rename/compat.h
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/test/rename/compat.h,v
retrieving revision 1.2
diff -u -r1.2 compat.h
--- compat.h 1998/04/11 10:20:37 1.2
+++ compat.h 1998/10/01 18:19:52
@@ -104,7 +104,6 @@
#define die ap_die
#define discard_request_body ap_discard_request_body
#define document_root ap_document_root
-#define dummy_mutex ap_dummy_mutex
#define each_byterange ap_each_byterange
#define error_log2stderr ap_error_log2stderr
#define escape_html ap_escape_html
Re: Removing ap_dummy_mutex from API
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Thu, 1 Oct 1998, Dan Jacobowitz wrote:
> But I believe that the point of MODULE_MAGIC_NUMBER_MAJOR was to
> indicate binary compatibility, right?
Yes. I'm starting to think the MODULE_MAGIC_NUMBER_MAJOR/MINOR thing is
overkill, and possibly a bad idea, since it leads to confusion as to what
are minor and what are major changes.
Perhaps we should go back to a single MODULE_MAGIC_NUMBER, and move to a
simpler binary-compatibility check: a simple
BINARY_COMPATIBLE_MAGIC_NUMBER define or such that gives the earliest
MODULE_MAGIC_NUMBER-compiled binary object that the server will run?
That seems less confusing to me.
(It also avoids a problem I see with the _MINOR/_MAJOR scheme, which is
how do you easily do #if checking in source in a manner that easily works
with both the old and new define schemes?)
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: Removing ap_dummy_mutex from API
Posted by Dan Jacobowitz <dr...@false.org>.
On Thu, Oct 01, 1998 at 06:20:44PM -0000, Ben Hyde wrote:
>
> This removes the global ap_dummy_mutex used in multithread.h
> as so:
>
> -#define ap_create_mutex(name) ((mutex *)ap_dummy_mutex)
> +#define ap_create_mutex(name) ((mutex *)-1)
>
> It is currently defined in http_main.c
> -/* this just need to be anything non-NULL */
> -void *ap_dummy_mutex = &ap_dummy_mutex;
>
> It's one of the four things that keeps one from using alloc.c
> buff.c, and ap/ standalone.
>
> It does change the API for unix only. You'll need to loadable modules
> which use mutex. So I bumped the MODULE_MAGIC_NUMBER_MINOR.
>
> Any complaints?
But I believe that the point of MODULE_MAGIC_NUMBER_MAJOR was to
indicate binary compatibility, right?
Dan
Re: Removing ap_dummy_mutex from API
Posted by Ben Hyde <bh...@pobox.com>.
Roy T. Fielding writes:
>My inclination would be to apply the patch the next time MMN is
>bumped for some other change, since it sounds like just a cleanup.
>
>....Roy
fair enough, I'll can wait.
- ben hyde
Re: Removing ap_dummy_mutex from API
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Without adding much value, I'll just note that the condition
handling scheme implemented in OpenVMS is truly elegant:
each stack frame can declare (or not) its own handler.
When an exception occurs, the OS walks up the stack frames,
giving each handler a shot at dealing with the exception.
The handlers can a) fix the problem and tell the OS to
restart the instruction that failed, b) say 'not my job'
and let the stack walk continue, or c) modify the condition
and unwind the stack as far as desired. The last was
particularly useful, as it allowed a condition handler to
turn a condition or exception into a return status one
level up.
This was designed over two decades ago, and I've longed
for its elegance and simplicity in every other environment.
Things like try/catch and the like are kludges beside it.
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://WWW.Dummies.Com/
Re: Removing ap_dummy_mutex from API
Posted by Ben Hyde <bh...@pobox.com>.
Simon Spero writes:
>This is also why garbage collection
Think of the ap_pools as ephemeral GC for C programmers :-).
Re: Removing ap_dummy_mutex from API
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 2 Oct 1998, Simon Spero wrote:
> This is also why garbage collection is so useful; all the conservative garbage
> collectors support finalizers, so you can collect OS resources as well as just
> memory. In Posix threads, the thread can chose whether to accept cancels or not. The
> two techniques combined make this problem a lot less hassle.
If the thread accepts cancels then all the libraries that it calls have to
accept cancels. Otherwise it has to wrap all the calls with pthreads
calls to disable and re-enable cancels. You have to assume that 3rd party
libraries have bugs with all forms of interruptions and cancels.
I don't see how garbage collection helps it. Sure, we have that with
pools. We can pick up any trash that's been recorded. But what we can't
do possibly is clean up some on-disk state that's messed. Like if you
were to cancel something in the middle of a dbm update...
Dean
Re: Removing ap_dummy_mutex from API
Posted by Simon Spero <se...@tipper.oit.unc.edu>.
This is also why garbage collection is so useful; all the conservative garbage
collectors support finalizers, so you can collect OS resources as well as just
memory. In Posix threads, the thread can chose whether to accept cancels or not. The
two techniques combined make this problem a lot less hassle.
Simon
Dean Gaudet wrote:
> Yup, and this is also why multiprocess models are still interesting :)
>
> Dean
>
> On Fri, 2 Oct 1998, Ben Hyde wrote:
>
> > Dean Gaudet writes:
> > > ... race conditions due to signals that I don't think are
> > >solveable. For example, if you take a signal inside a 3rd party
> > >library... you're toast. You can't expect it to continue properly (some
> > >do, some don't), and you can't longjmp out of it because it could leak
> > >resources. The only way around it is to not take the signal.
> >
> > That does seem to be the industry solution. Nobody (aka 3rd party
> > code) implemented interrupt handling right in their code and meanwhile
> > longjmp is rarely dependable either. So we all end up deciding to
> > forswear interrupts.
> >
> > Tuning in latter...
> > Mr. Application say:
> > "What happens when a thread/process gets stuck, errors, or runs out of time?"
> > Mr. OS say:
> > "You could have another thread kill it."
> > A: "Can I clean up?"
> > O: "Not really, but the thread that kills it can."
> > A: "Oh so I build my own stack of cleanup."
> > O: "You got it."
> > A: "wonderful"
> > O: "Don't worry the OS data structures will be reclaimed."
> >
> > Good thing we got those pools and with their cleanup routines per thread in 2.
> >
> > - ben
> >
Re: Removing ap_dummy_mutex from API
Posted by Dean Gaudet <dg...@arctic.org>.
Yup, and this is also why multiprocess models are still interesting :)
Dean
On Fri, 2 Oct 1998, Ben Hyde wrote:
> Dean Gaudet writes:
> > ... race conditions due to signals that I don't think are
> >solveable. For example, if you take a signal inside a 3rd party
> >library... you're toast. You can't expect it to continue properly (some
> >do, some don't), and you can't longjmp out of it because it could leak
> >resources. The only way around it is to not take the signal.
>
> That does seem to be the industry solution. Nobody (aka 3rd party
> code) implemented interrupt handling right in their code and meanwhile
> longjmp is rarely dependable either. So we all end up deciding to
> forswear interrupts.
>
> Tuning in latter...
> Mr. Application say:
> "What happens when a thread/process gets stuck, errors, or runs out of time?"
> Mr. OS say:
> "You could have another thread kill it."
> A: "Can I clean up?"
> O: "Not really, but the thread that kills it can."
> A: "Oh so I build my own stack of cleanup."
> O: "You got it."
> A: "wonderful"
> O: "Don't worry the OS data structures will be reclaimed."
>
> Good thing we got those pools and with their cleanup routines per thread in 2.
>
> - ben
>
Re: Removing ap_dummy_mutex from API
Posted by Ben Hyde <bh...@pobox.com>.
Dean Gaudet writes:
> ... race conditions due to signals that I don't think are
>solveable. For example, if you take a signal inside a 3rd party
>library... you're toast. You can't expect it to continue properly (some
>do, some don't), and you can't longjmp out of it because it could leak
>resources. The only way around it is to not take the signal.
That does seem to be the industry solution. Nobody (aka 3rd party
code) implemented interrupt handling right in their code and meanwhile
longjmp is rarely dependable either. So we all end up deciding to
forswear interrupts.
Tuning in latter...
Mr. Application say:
"What happens when a thread/process gets stuck, errors, or runs out of time?"
Mr. OS say:
"You could have another thread kill it."
A: "Can I clean up?"
O: "Not really, but the thread that kills it can."
A: "Oh so I build my own stack of cleanup."
O: "You got it."
A: "wonderful"
O: "Don't worry the OS data structures will be reclaimed."
Good thing we got those pools and with their cleanup routines per thread in 2.
- ben
Re: Removing ap_dummy_mutex from API
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 2 Oct 1998, Ben Hyde wrote:
> How's it do a timeout without an interupt?
The only timeouts we've ever used are on socket i/o... and NSPR implements
that directly with a timeout on PR_Send() and PR_Recv(). So I put a
timeout into BUFF... and a callback for when the timeout is triggered.
Search for ap_bonerror() to see how it's used.
> Recalling that I couldn't find a way to interupt a thread on NT that's
> I'll accept that no interupts is the future. I like interupts and
> don't quite know how you write code that avoids them without polling
> (aka non-preemptive multitasking).
pre-emption is fine with me.
What I don't like are interrupted and restarted system calls. Apache 1.3
has various race conditions due to signals that I don't think are
solveable. For example, if you take a signal inside a 3rd party
library... you're toast. You can't expect it to continue properly (some
do, some don't), and you can't longjmp out of it because it could leak
resources. The only way around it is to not take the signal.
Dean
Re: Removing ap_dummy_mutex from API
Posted by Ben Hyde <bh...@pobox.com>.
Dean Gaudet writes:
>On Thu, 1 Oct 1998, Ben Hyde wrote:
>> 1. libab is dependent ap_log_error because of ap_slack.
> ... function pointer ...
that will be better...
>> 2. the stack/interrupt stuff is all in http_main. Linker
>> doesn't like that since alloc wants to use ap_block_alarms.
>> In the longer term I don't like it since the stack/interrupt
>> stuff is really very low level and ought to be in it's own
>> file.
>
>ap_block_alarms is gone in apache-nspr. There's no interrupts, there's no
>longjmp()s. Say 'yay' :)
How's it do a timeout without an interupt?
Recalling that I couldn't find a way to interupt a thread on NT that's
I'll accept that no interupts is the future. I like interupts and
don't quite know how you write code that avoids them without polling
(aka non-preemptive multitasking).
"yay", "yay"... I'll practice.
- ben hyde
Re: Removing ap_dummy_mutex from API
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 1 Oct 1998, Ben Hyde wrote:
> 1. libab is dependent ap_log_error because of ap_slack.
In the past I've solved this by having a generic error routine, and a
function pointer to it... then using the function pointer in the
library... and overriding it in whatever apps want more control.
> 2. the stack/interrupt stuff is all in http_main. Linker
> doesn't like that since alloc wants to use ap_block_alarms.
> In the longer term I don't like it since the stack/interrupt
> stuff is really very low level and ought to be in it's own
> file.
ap_block_alarms is gone in apache-nspr. There's no interrupts, there's no
longjmp()s. Say 'yay' :)
> 3. This silly ap_dummy_mutex thing.
This is gone too...
Dean
Re: Removing ap_dummy_mutex from API
Posted by Ben Hyde <bh...@pobox.com>.
Roy T. Fielding writes:
>>This removes the global ap_dummy_mutex used in multithread.h
...
>I couldn't figure out from your description why this was necessary.
>Could you explain? Just a short note -- I am mostly curious because
>I'm not sure what it was doing there in the first place.
In the first place? Well on unix the mutex calls are all no-ops,
but create_mutex has to return something. For reasons lost in
the mists of time the original author wrote that. It's a clever
cliche for getting a unique value, but I don't see any reason
for it. It just creates a lot of lines of code mentioning
the symbol that amount to nothing.
Necessary? no but why I care...
I've been writting little applications of various sorts that
use alloc.c and buff.c. These are fun and show that there
is almost a nice little "server" toolkit hidden in the apache
sources.
I currently have a file I call stubs.c that defines assorted
things so I can link. The file illustrates how the layering of
the code isn't perfect. It's pretty good, but just a little
short of perfect.
There are three problems in there.
1. libab is dependent ap_log_error because of ap_slack.
2. the stack/interrupt stuff is all in http_main. Linker
doesn't like that since alloc wants to use ap_block_alarms.
In the longer term I don't like it since the stack/interrupt
stuff is really very low level and ought to be in it's own
file.
3. This silly ap_dummy_mutex thing.
- ben hyde