Re: Removing ap_dummy_mutex from API

["Roy T. Fielding" <fi...@kiwi.ics.uci.edu>]

>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.

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.

....Roy

Re: Removing ap_dummy_mutex from API

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

Re: Removing ap_dummy_mutex from API

[Dean Gaudet <dg...@arctic.org>]

It was there because I didn't want to pick an arbitrary non-NULL constant
to cast.  So I just put in a global and used that.  It doesn't really
matter, nothing should use it.

Dean

On Thu, 1 Oct 1998, Roy T. Fielding 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.
> 
> 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.
> 
> ....Roy
>