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 Laurie <be...@algroup.co.uk> on 1999/08/20 19:00:33 UTC
Re: First in a long line of APR related patches.
Ryan Bloom wrote:
>
> I am posting a VERY large patch here. This is the first APR patch, and it
> MUST be reviewed before it is commited. This patch changes almost every
> file in the server. It changes all the apache pools into APR contexts.
> This was debated a while ago, and we decided to let the issue sit until we
> were ready to put contexts into apache. Well, here we are. With this
> patch, the server does NOT run. It builds, but it doesn't link. I know
> what 99% of the linker problems are, but I don't have time to fix them
> today. I'll hopefully get them done on the plane to Monterey tomorrow. I
> will NOT commit until the server runs and serves pages again.
Arg. I've totally forgotten what the difference between a context and
pool was, and I'm about go on holiday again. Is there an executive
summary?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: async not./canc. (was Re: First in a long line of APR related patches.)
Posted by Dean Gaudet <dg...@arctic.org>.
On Wed, 25 Aug 1999, Manoj Kasichainula wrote:
> On Wed, Aug 25, 1999 at 04:01:58PM -0700, Dean Gaudet wrote:
> > I've pointed out that pools aren't as useful in a threaded environment...
>
> Why not? I'm curious. Because the per-thread pools can't share their
> free memory?
pools are useful on a per-request basis -- pools are best suited to
allocations which all get freed at the same time. An example where
they're not useful would be a cache. We don't cache anything currently,
because there's little benefit to caching without threads... but with
threads, we'll start having caches. And for those we need a free()
implementation... we could retrofit it on top of pools, but that would
defeat the simplicity of what's already there.
Another example would be an IMAP server -- some things, like the memory
allocated to process a particular command, fit well with pools. But there
is a lot of per-session data which needs free().
> > and I think we'll find that having them in every APR function is going to
> > weigh things down even more.
>
> Some of the APR functions will need memory (and yeah, this should be
> minimized, but I don't think it can be avoided). I can think of 4 ways
> to give APR this memory
>
> 1. give it pools to allocate it from
> 2. let it use malloc/free (what NSPR does)
> 3. give APR function pointers to a custom malloc/free
> 4. require the caller to preallocate all APR structures before the APR
> calls are made
>
> I'm happiest with 1 or 4, but I'd think all of them would cause equal
> amounts of added weight. What do you have in mind?
Yeah it's a hard one. (The C++ers are probably ready to jump in around
here.)
I've recently been using a library which does 3 + 4. When initializing an
object you pass the library the memory for the object, and the free()
function for the object (and a void *). I'm finding it extremely clumsy.
I would be a lot happier with an "allocation context" ... which is sort
of where APR has gone :)
> > Pools are also less useful when there is no async cancellation...
>
> Maybe, but they still are really nice because they essentially give us
> the semantics of a garbage-collection-based language, meaning we don't
> have to worry about annoying problems like who owns which blocks of
> memory. They made my reentry into C from JavaLand much more pleasant.
Yup, they're useful for that.
But I'm guessing we'll need to modify them slightly...
hmm. how about this. memory is treated specially in pools currently,
unlike the other resources we drop in pools, memory isn't attached via a
cleanup. maybe we want to abstract the memory so that we can have pools
which use malloc/free directly and pools which use the cheap block
allocator we have now.
Dean
Re: async not./canc. (was Re: First in a long line of APR related patches.)
Posted by Manoj Kasichainula <ma...@io.com>.
On Wed, Aug 25, 1999 at 04:01:58PM -0700, Dean Gaudet wrote:
> I've pointed out that pools aren't as useful in a threaded environment...
Why not? I'm curious. Because the per-thread pools can't share their
free memory?
> and I think we'll find that having them in every APR function is going to
> weigh things down even more.
Some of the APR functions will need memory (and yeah, this should be
minimized, but I don't think it can be avoided). I can think of 4 ways
to give APR this memory
1. give it pools to allocate it from
2. let it use malloc/free (what NSPR does)
3. give APR function pointers to a custom malloc/free
4. require the caller to preallocate all APR structures before the APR
calls are made
I'm happiest with 1 or 4, but I'd think all of them would cause equal
amounts of added weight. What do you have in mind?
> Pools are also less useful when there is no async cancellation...
Maybe, but they still are really nice because they essentially give us
the semantics of a garbage-collection-based language, meaning we don't
have to worry about annoying problems like who owns which blocks of
memory. They made my reentry into C from JavaLand much more pleasant.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"Violence is the first refuge of the violent." - Aaron Allston
Re: async not./canc. (was Re: First in a long line of APR related patches.)
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 26 Aug 1999, Ryan Bloom wrote:
> If NSPR was perfect, we would have used it.
When did I say NSPR was perfect? I am just pointing out things which I
think they did right, and directions I think you're going wrong.
> Wrong. I am working on a Portable Run-time for use in Apache, and
> hopefully other projects. If all we want, is a VERY specific portable
> run-time that is only useful for Apache, fine.
You have one user currently, and if you're not satisfying the needs of
that user, then what are you doing?
> > I'm saying this with a lot of experience: when people design libraries to
> > be as general as possible they end up with a bloated piece of code that
> > does not perform the jobs it needs to perform well. Sure, maybe 5 years
> > down the road someone will need one of those features, but will the
> > library actually have survived that long? Or will it be replaced with
> > something that did the job that was required at design time?
> >
> > We can also take this point of view: eliminating asynchronous
> > notification/cancellation is a *breakthough* that we are making in server
> > development. Based on our experience within Apache we have learned that
> > async not./canc. suck. We, that is the Apache developers, think that this
> > is one of the new goals for server development which we would like others
> > to follow.
>
> What experience? Last I checked, threads were introduced into Apache in
> the current development release. Sure, others have put them in in the
> apst, but we STILL haven't released a server with threads.
Hmm, apache 1.3.x on windows uses threads, or am I on crack?
How is it relevant what we've released? There have been about six
threaded ports now. Have you ever sat down and worked through the signal
complexity in 1.x? I doubt you have. I have. In the 1.2 debugging cycle
I fixed *A LOT* of race conditions surrounding signals. And in 1.3 I
tried to make it all work together, fast. And I found it was bloody hard
-- and 1.3 is left with a few race conditions surrounding signals. I just
gave up at some point, it is far far far too complex to have async
notification. I've talked with other folks (not apache) about this as
well, I'm not alone in this opinion.
> This is not a compelling argument, IMHO. Yes, many libraries aren't
> signal safe. So, does this mean that we should contribute to this
> problem? I sure hope not. I would much rather be a part of the solution.
You can be part of the solution by providing a new paradigm.
Dean
Re: async not./canc. (was Re: First in a long line of APR related
patches.)
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> > I don't especially care what NSPR did with regard to async thread
> > cancellation.
>
> I think you should. I think you're wasting someone else's fine research
> efforts, and are bound to make some mistakes. You don't necessarily need
> to look at NSPR, because I have -- and I'm happy pointing out the design
> choices they made when I feel you're making a mistake.
If NSPR was perfect, we would have used it. There were some gaping holes
in NSPR, (processes is a big one) and the general feeling was it was too
big to include in apache. Sometimes NSPR did the right thing, sometimes
they didn't. I get the feeling, that somethings they didn't implement
featuers because they didn't need them. When I originally put in the
thread cancelation flag, it was because Manoj requested it.
He needed a way to cancel threads when a process was about to quit. In
fact, everything in APR-contexts, except for pools, was requested by
somebody else. Manoj wanted the thread and signal flags, and somebody, I
think it was Ben, wanted user-data (this was in the first discussion about
contexts, so I would have to look up who requested it).0
>
> > There are people outside of the Apache group who may want
> > to have asynch thread cancellation in other non-ASF related projects.
>
> My opinion is that you are not helping build apache then, you're working
> on your own project, that's unfortunate.
Wrong. I am working on a Portable Run-time for use in Apache, and
hopefully other projects. If all we want, is a VERY specific portable
run-time that is only useful for Apache, fine. We have it. It's
sprinkled throughout the code, and it can be found by looking for the
ifdef's. I was under the impression we wanted more than that. We wanted
a general purpose Run-time based on our work on Apache. If I'm wrong,
then tell me. I'll stop working as hard as I am.
> Again, and I sound like a broken record: demonstrate a need!
The need was there when I designed it. It was requested of APR.
>
> I'm saying this with a lot of experience: when people design libraries to
> be as general as possible they end up with a bloated piece of code that
> does not perform the jobs it needs to perform well. Sure, maybe 5 years
> down the road someone will need one of those features, but will the
> library actually have survived that long? Or will it be replaced with
> something that did the job that was required at design time?
>
> We can also take this point of view: eliminating asynchronous
> notification/cancellation is a *breakthough* that we are making in server
> development. Based on our experience within Apache we have learned that
> async not./canc. suck. We, that is the Apache developers, think that this
> is one of the new goals for server development which we would like others
> to follow.
What experience? Last I checked, threads were introduced into Apache in
the current development release. Sure, others have put them in in the
apst, but we STILL haven't released a server with threads. Yes, I agree
99% of the time, async. canc. is a REALLY BAD idea. I don't want to use
it most of the time, but once it a while, it is useful. Usually, when the
process is about to go down, and you just want to stop the other threads
from interfering with your cleanup process.
> One more point: APR is but one library. If people code with signals,
> then they need all their libraries to behave well. This is not the case
> for (m)any third party libraries. In fact, this is one of my motivations
> for pushing us down the road of no signals. So... even if APR played
> signal games, folks would still run into troubles with other libraries.
> It seems to me like you gain nothing from having the signal masking.
This is not a compelling argument, IMHO. Yes, many libraries aren't
signal safe. So, does this mean that we should contribute to this
problem? I sure hope not. I would much rather be a part of the solution.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
async not./canc. (was Re: First in a long line of APR related patches.)
Posted by Dean Gaudet <dg...@arctic.org>.
On Tue, 24 Aug 1999, Ryan Bloom wrote:
> I don't especially care what NSPR did with regard to async thread
> cancellation.
I think you should. I think you're wasting someone else's fine research
efforts, and are bound to make some mistakes. You don't necessarily need
to look at NSPR, because I have -- and I'm happy pointing out the design
choices they made when I feel you're making a mistake.
> There are people outside of the Apache group who may want
> to have asynch thread cancellation in other non-ASF related projects.
My opinion is that you are not helping build apache then, you're working
on your own project, that's unfortunate.
> I want to have that ability in APR if other projects want it.
Again, and I sound like a broken record: demonstrate a need!
I'm saying this with a lot of experience: when people design libraries to
be as general as possible they end up with a bloated piece of code that
does not perform the jobs it needs to perform well. Sure, maybe 5 years
down the road someone will need one of those features, but will the
library actually have survived that long? Or will it be replaced with
something that did the job that was required at design time?
We can also take this point of view: eliminating asynchronous
notification/cancellation is a *breakthough* that we are making in server
development. Based on our experience within Apache we have learned that
async not./canc. suck. We, that is the Apache developers, think that this
is one of the new goals for server development which we would like others
to follow.
We don't have to carry forward all mistakes.
> I am more concerned with the flexability that contexts can give us in the
> future. I want to know that if there is information that most or all APR
> APR functions need access to, there is an obvious place to put it. Pools
> are for memory management, and adding more to them just muddies their
> purpose.
I've pointed out that pools aren't as useful in a threaded environment...
and I think we'll find that having them in every APR function is going to
weigh things down even more.
Pools are also less useful when there is no async cancellation...
> As far as only having a single void * for user data, what else
> do you want? Yes, we could put together a whole API for user data, I'm
> not stopping you. I haven't done it yet. I have other things I am
> working on, right now, so it is low on my prioity list.
I don't see the need for even the void * -- you're the one who implemented
it, so surely it's fine for me to ask you how you intended it to be used?
If you haven't figured that out yet, then why are you bloating the
interface with it?
Also, the signal/no-signal thing is "user data", the user is APR. You
have the hint of a generic context data technique, but you didn't use it
for your own data...
Ryan, what I'm saying is based on my experience, and based on the
direction that I think server development should move in. You may have
other experience which you haven't shared with me yet that says these
aren't mistakes. But I think you'll find a pattern in all of my
complaints (not just against this, but in other threads): I don't like
features for the sake of features. I prefer to see applications for
features before the features are considered... and I prefer to see
features which solve many applications over features which solve a single
application.
One more point: APR is but one library. If people code with signals,
then they need all their libraries to behave well. This is not the case
for (m)any third party libraries. In fact, this is one of my motivations
for pushing us down the road of no signals. So... even if APR played
signal games, folks would still run into troubles with other libraries.
It seems to me like you gain nothing from having the signal masking.
Dean
Re: First in a long line of APR related patches.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
I am keeping this short, because my dial-up connection keeps dyting on me.
The signal stuff isn't really signal-safeness. It is really, should we be
acting on signals when in the APR code. It is more or less a way of
saying, block all signals inside APR functions. I was giving two examples
of things APR could do for us.
I don't especially care what NSPR did with regard to async thread
cancellation. There are people outside of the Apache group who may want
to have asynch thread cancellation in other non-ASF related projects. I
want to have that ability in APR if other projects want it.
I am more concerned with the flexability that contexts can give us in the
future. I want to know that if there is information that most or all APR
APR functions need access to, there is an obvious place to put it. Pools
are for memory management, and adding more to them just muddies their
purpose. As far as only having a single void * for user data, what else
do you want? Yes, we could put together a whole API for user data, I'm
not stopping you. I haven't done it yet. I have other things I am
working on, right now, so it is low on my prioity list.
I won't be logging on anymore util I get home tomorrow night, but I'll
respond to everything else then. I will hopefully be posting a complete
patch that allows Apache to serve pages while using contexts.
Ryan
On Tue, 24 Aug 1999, Manoj Kasichainula wrote:
> On Tue, Aug 24, 1999 at 01:30:43AM -0700, Dean Gaudet wrote:
> > what would APR do differently when told to be signal safe versus not?
>
> I have to actaully look at the code, but I believe it will just mask
> out signals on the way in and unmask them on the way out. Ryan?
>
> --
> Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: First in a long line of APR related patches.
Posted by Manoj Kasichainula <ma...@io.com>.
On Tue, Aug 24, 1999 at 01:30:43AM -0700, Dean Gaudet wrote:
> what would APR do differently when told to be signal safe versus not?
I have to actaully look at the code, but I believe it will just mask
out signals on the way in and unmask them on the way out. Ryan?
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
memmgt (Re: First in a long line of APR related patches.)
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 26 Aug 1999, Ryan Bloom wrote:
> BTW, one of the places that the context is nicer than the pool, IMHO, is
> the abstraction. This lets me do multiple things that IMO are harder to
> do with just pools.
Well that's only because you refuse to accept that you could stick a (void
*) into a pool just as easily ;)
Apache will need all those memory abstractions at the same time -- a
compile time switch won't help at all.
Dean
Re: First in a long line of APR related patches.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
BTW, one of the places that the context is nicer than the pool, IMHO, is
the abstraction. This lets me do multiple things that IMO are harder to
do with just pools.
We have already had one person ask for APR without the requirement of
having to pass pools around. How do we do that without relying on
malloc/free, which has also been discouraged?
Dean, has suggested possibly changing the way pools work, to treat memory
just like any other pool-ed resource. (Hanging it off a clean-up).
Plus, we have Ralf's mm-pools, which use pools in shared memory.
Not to mention, the possibility of having a memory-management scheme like
pools, only with the ability to shrink as well as grow.
If we have to pass pools around, this abstraction is hard to acheive. If
we pass around contexts, with one field being a "pool"-like structure,
this is easy. On a non-pool'ed system, that field is either always NULL,
or just not there, on any other system, where memory management is handled
by apr functions, that field is wahtever structure makes sense.
I envision something like this (in the not-so-distant future)
typedef ap_context_t {
#if USE_POOLS
/* Standard Apache 1.3 pools */
ap_pool_t *pool;
#elif USE_SHRINK_POOL
/* Pools that can shrink */
ap_shrink_pool_t *pool;
#elif USE_FOOBAR
/* Some new memory manager we haven't discussed yet.
ap_foobar_t *pool;
#else
/* Use malloc/free, and put nothing there. */
#endif
void *user_data;
} ap_context_t;
This lets me write any program using any memory manager, and have it
choose which memory manager scheme to use during compile time. Yes, this
can be done with typedefs, but I really think this is easier to debug.
Plus, this gives us the user data stuff.
Do I have a compelling need for user data? Yes and no. I like the idea
of putting the user data in a single location for all of the Apache
structures. But it isn't really necessary.
It has been requested, and no, I don't remember who wanted it, that all
APR types have a place for user data. This makes sense to me. It allows
people to attach data to any apr structure when it is created, and know
that data will go away when the strcuture goes away. Putting the
user-data in the context, which all APR types have, seems like the best
way to implement this. But, that is of course, MHO.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: First in a long line of APR related patches.
Posted by Dean Gaudet <dg...@arctic.org>.
On Tue, 24 Aug 1999, Manoj Kasichainula wrote:
> Is there actually much of a problem with third-party libs generating
> signals and cancellations? In 1.3, you had to worry about 3rd-party
> libs that couldn't handle receiving signals, but since the predominant
> Unix MPMs in 2.0 will never use cancellations or (hopefully) signals
> in the worker threads, the only concern is third-party libraries that
> rely on generating and receiving signals. Is this a real problem?
given that apache won't be using the signals, i don't see what the problem
is.
i doubt that any third party library would be sending an async
cancellation to a thread spawned by apache... maybe to a thread spawned by
the library (heh, like there are 3rd party threadsafe, thread-using
libraries anyhow!).
> > > Yeah, one alternative is for modules to do this themselves, instead of
> > > relying on APR to block signals. I don't think that's too bad, but it
> > > could get messy.
> >
> > Modules can alway screw the server over, is it worth it to "fix" one small
> > leak when they can punch a hole elsewhere?
>
> Well, this isn't fixing a leak, really. It's more like letting modules
> that use signals make APR calls without having to wrap them in signal
> blocks/unblocks all the time. The module would be responsible for
> setting and unsetting the signal-safe flag in the context, not Apache.
> But, you're right; if that's the only thing contexts were used for,
> they wouldn't be worth it.
what would APR do differently when told to be signal safe versus not?
Dean
Re: First in a long line of APR related patches.
Posted by Manoj Kasichainula <ma...@io.com>.
On Mon, Aug 23, 1999 at 11:57:11PM -0700, Dean Gaudet wrote:
> On Sun, 22 Aug 1999, Manoj Kasichainula wrote:
> > On Fri, Aug 20, 1999 at 10:19:26PM -0700, Dean Gaudet wrote:
> > > async notification/cancellation are bad/non-portable...
> >
> > yes, they are bad. But, third-party modules will end up using them,
> > unless we ban it. We don't want to bother with blocking and unblocking
> > signals+cancellation for every APR call inside Apache proper (well, at
> > least we don't with the mpmt_pthread and dexter MPMs), but we do
> > inside some third-party modules.
>
> So you're saying, "I understand it sucks, some people might want it, and
> I'm going to help them do it". Interesting. That wouldn't be motivation
> for me.
I did say "unless we ban it". I'm all for saying that if a module uses
signal-like constructs in any way and this breaks Apache, the module
must fix it, and in fact, I think we are saying it.
The only question then is whether to give module authors that are
working with cranky third-party libraries help so that their code is a
little less painful. I'd love to take a draconian Linus-like stance
here and say that dealing with binary-only bogocities is not Apache's
problem, and we won't help at all. But, I'm guessing people will
object.
Is there actually much of a problem with third-party libs generating
signals and cancellations? In 1.3, you had to worry about 3rd-party
libs that couldn't handle receiving signals, but since the predominant
Unix MPMs in 2.0 will never use cancellations or (hopefully) signals
in the worker threads, the only concern is third-party libraries that
rely on generating and receiving signals. Is this a real problem?
> > Yeah, one alternative is for modules to do this themselves, instead of
> > relying on APR to block signals. I don't think that's too bad, but it
> > could get messy.
>
> Modules can alway screw the server over, is it worth it to "fix" one small
> leak when they can punch a hole elsewhere?
Well, this isn't fixing a leak, really. It's more like letting modules
that use signals make APR calls without having to wrap them in signal
blocks/unblocks all the time. The module would be responsible for
setting and unsetting the signal-safe flag in the context, not Apache.
But, you're right; if that's the only thing contexts were used for,
they wouldn't be worth it.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
'I think they're the tools of the devil... They scare me."
-- Marilyn Manson on Hanson
Re: First in a long line of APR related patches.
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 22 Aug 1999, Manoj Kasichainula wrote:
> On Fri, Aug 20, 1999 at 10:19:26PM -0700, Dean Gaudet wrote:
> > On Fri, 20 Aug 1999, Ryan Bloom wrote:
> >
> > > allowing us to control how the underlying APR layer works. Is the APR
> > > layer signal safe, are threads cancelable inside APR functions., etc.
> >
> > async notification/cancellation are bad/non-portable...
>
> yes, they are bad. But, third-party modules will end up using them,
> unless we ban it. We don't want to bother with blocking and unblocking
> signals+cancellation for every APR call inside Apache proper (well, at
> least we don't with the mpmt_pthread and dexter MPMs), but we do
> inside some third-party modules.
So you're saying, "I understand it sucks, some people might want it, and
I'm going to help them do it". Interesting. That wouldn't be motivation
for me.
NSPR doesn't have async notification. Draw your own conclusions.
> Yeah, one alternative is for modules to do this themselves, instead of
> relying on APR to block signals. I don't think that's too bad, but it
> could get messy.
Modules can alway screw the server over, is it worth it to "fix" one small
leak when they can punch a hole elsewhere?
Dean
Re: First in a long line of APR related patches.
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Sun, 22 Aug 1999, Manoj Kasichainula wrote:
> On Fri, Aug 20, 1999 at 10:19:26PM -0700, Dean Gaudet wrote:
> > On Fri, 20 Aug 1999, Ryan Bloom wrote:
> >
> > > allowing us to control how the underlying APR layer works. Is the APR
> > > layer signal safe, are threads cancelable inside APR functions., etc.
> >
> > async notification/cancellation are bad/non-portable...
>
> yes, they are bad. But, third-party modules will end up using them,
> unless we ban it.
.... or the API provides such good alternatives/ways-to-do-it that you do
not need them. Because it is a thing which is tempting, which you 'want'
to allow for in a third party module, or worse, shared library in
binary-only form. The ldap/whois++ module I was looking at recently was a
case in point.
Dw.
Re: First in a long line of APR related patches.
Posted by Manoj Kasichainula <ma...@io.com>.
On Fri, Aug 20, 1999 at 10:19:26PM -0700, Dean Gaudet wrote:
> On Fri, 20 Aug 1999, Ryan Bloom wrote:
>
> > allowing us to control how the underlying APR layer works. Is the APR
> > layer signal safe, are threads cancelable inside APR functions., etc.
>
> async notification/cancellation are bad/non-portable...
yes, they are bad. But, third-party modules will end up using them,
unless we ban it. We don't want to bother with blocking and unblocking
signals+cancellation for every APR call inside Apache proper (well, at
least we don't with the mpmt_pthread and dexter MPMs), but we do
inside some third-party modules.
Yeah, one alternative is for modules to do this themselves, instead of
relying on APR to block signals. I don't think that's too bad, but it
could get messy.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
Re: First in a long line of APR related patches.
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Dean Gaudet wrote:
>
> how do you manage the user data? it looks like there's only one
> void * per context...
That's as much as we have now inside Apache, and it seems to
work. The access mechanism is still lacking, though, I think --
the APR equivalent of ap_{get,set}_module_config().
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://ASFD.MeepZor.Com/>
Re: First in a long line of APR related patches.
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 20 Aug 1999, Ryan Bloom wrote:
> allowing us to control how the underlying APR layer works. Is the APR
> layer signal safe, are threads cancelable inside APR functions., etc.
async notification/cancellation are bad/non-portable...
> It
> also provides an easy place to put user data, which can be used for asynch
> I/O. This also provides a measure of freedom for the future.
how do you manage the user data? it looks like there's only one void *
per context...
Dean
Re: First in a long line of APR related patches.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Executive Summary of contexts vs pools:
A pool is used exclusively for memory management. Allocating, freeing,
etc.
A context allows us to do a bit more. It manages memory, as well as
allowing us to control how the underlying APR layer works. Is the APR
layer signal safe, are threads cancelable inside APR functions., etc. It
also provides an easy place to put user data, which can be used for asynch
I/O. This also provides a measure of freedom for the future.
It is important to realize that this has no bearing on variable names. I
have this all over the place in my patch:
ap_context_t *pool.
That's it. I have been trapped on a plane all day, so I'm keeping things
short today;.
Ryan
>
> Arg. I've totally forgotten what the difference between a context and
> pool was, and I'm about go on holiday again. Is there an executive
> summary?
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
> - Indira Gandhi
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.