httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: work in progress: mpm-3.tar.gz (fwd)
Date Sat, 19 Jun 1999 22:35:23 GMT
On Sat, 19 Jun 1999, Dean Gaudet wrote:

>     FILE *f = fopen("foo", "r");
> You may now use f in any thread.  There's no requirement that f be used
> only in the thread which created it.  I don't see why such a requirement
> is necessary!  If libc didn't keep everything it needed to know in the
> structure pointed to by f, why does it have a structure to begin with?

BTW -- I'm not saying anything about f being used simultaneously by
multiple threads.  I'm suggesting that f can be used by multiple threads
provided they all take care to avoid using it at the same time.  I think
it's totally reasonable for a library to provide an interface which is
thread-safe, but doesn't provide any of its own locking.  In fact, that's
totally the right way to do things... because frequently locking isn't
even required.

zlib for example, hangs all of its data off a z_stream.  If I want
multiple threads to write through a single z_stream then I have to provide
my own locking... but I know that as long as I'm serializing access to
each z_stream I'm still free to use it from any thread.

In general though, I probably don't need multiple threads writing through
one z_stream... what I probably have are multiple z_streams, and multiple
threads... and how I choose to multiplex the two is up to me.  The library
doesn't force me into any model. 

That's a good library.  It would have to bend over backwards to be stupid

Can you give me an example of a "thread-safe" library which just doesn't
work this way?

Note that I'm not changing the thread running the code in the middle of
anything -- it's at very defined points in the execution, and those points
are definately not in the middle of the library... the stack trace
looks roughly like this:

#0 third_party_library()
#1 third_party_module()
#2 apache_core_code()
#3 mpm_core_code()
#4 http_main_code()

thread switches can only occur at the #3 level... which means the stack
has to unwind, the #0, #1, and #2 functions have to return before #3
can choose to use a different thread... so later it may be:

#0 third_party_library_2()
#1 third_party_module_2()
#2 apache_core_code_2()
#3 mpm_core_code()
#4 http_main_code()

In a different thread, but all the earlier stuff has returned... there's
no longjmping...

Does it make sense?

It actually may never happen either -- the only phase I want it for
is the handler phase, and the subsequent log_handler.  But Tony asked
about DNS, and to have async support for DNS means that this unwinding
and switching can happen in any phase.  But if it makes you happier I
can just say that the log_transaction phase may occur in a different
thread from the rest of the request... but I'm loathe to do that until
someone actually comes up with a library which requires this.


View raw message