On Tue, Jul 17, 2001 at 10:12:35AM -0700, Aaron Bannert wrote:
- Optionally creating a child-pool for each thread. This provides us two
things in my mind:
1) Allowing the application to choose an SMS for this thread-pool (which
could very well be a special SMS created just for this
: Re: [PATCH] Problems with MPM threaded
On Sat, 14 Jul 2001 [EMAIL PROTECTED] wrote:
Having multiple processes each with multiple threads provides for FAR
more robustness than just a single process with multiple threads.
ya know, i'm not really convinced of the desirability of this explanation
On Sat, 14 Jul 2001 [EMAIL PROTECTED] wrote:
Having multiple processes each with multiple threads provides for FAR
more robustness than just a single process with multiple threads.
ya know, i'm not really convinced of the desirability of this explanation
anymore. maybe the hypothetical buggy
On Sat, 14 Jul 2001, Roy T. Fielding wrote:
The correct fix, as I see it, is to kill off the interprocess
accept lock by removing the possibility of having other processes
in a *threaded* MPM. -- justin
That architecture was explored in detail by Netscape. It isn't reliable
and
Normally this would be done (in POSIX) with pthread_cancel(), passing it
the pthread_t from the other thread.
Unfortunately, this is not a part of APR because many of the current OS
implementations of this mechanism will leak resources (aparently in the
kernel), and that is bad.
-aaron
On
On Tue, Jul 17, 2001 at 01:29:47AM -0700, dean gaudet wrote:
On Sun, 15 Jul 2001, Sander Striker wrote:
Why are we so desperate in opting out the child-pool creation?
I don't really have problems with a child pool for each thread. Actually,
it will make the dynamic locking a lot easier
Uh...you knew that already, didn't you... duh...
jeez now i'm the smartass ;)
-aaron
On Tue, Jul 17, 2001 at 08:43:18AM -0700, Aaron Bannert wrote:
Normally this would be done (in POSIX) with pthread_cancel(), passing it
the pthread_t from the other thread.
Unfortunately, this is not a
From: [EMAIL PROTECTED]
Sent: Tuesday, July 17, 2001 11:13 AM
I believe that the problem is that the threaded code is creating the
pool, and not advertising it to the thread itself. This is an easy thing
to fix. I do not agree that every APR app that uses threads should have
to create
William A. Rowe, Jr. wrote:
From: [EMAIL PROTECTED]
Sent: Tuesday, July 17, 2001 11:13 AM
I believe that the problem is that the threaded code is creating the
pool, and not advertising it to the thread itself. This is an easy thing
to fix. I do not agree that every APR app that uses threads
I'm not sure that the alternative is workable, either.
At the time of the fork, when the child process gets a snapshot of
the parent's memory, it's possible that some thread other than the one
invoking fork could be halfway through registering a new resource (e.g.,
file descriptor) in its
We have hit an impass in my mind. Dean and I are saying that having each
thread have it's own pool is a requirement. Not just for httpd, but for
anything using pools. Dean, if I am mis-interpreting you, then I am
sorry, and please correct me.
Aaron, you disagree. you want each app to
Aaron Bannert wrote:
I'm not sure that the alternative is workable, either.
At the time of the fork, when the child process gets a snapshot of
the parent's memory, it's possible that some thread other than the one
invoking fork could be halfway through registering a new resource (e.g.,
file
On Tue, Jul 17, 2001 at 10:17:01AM -0700, Brian Pane wrote:
Aaron Bannert wrote:
I'm not sure that the alternative is workable, either.
At the time of the fork, when the child process gets a snapshot of
the parent's memory, it's possible that some thread other than the one
invoking fork
Aaron Bannert wrote:
On Tue, Jul 17, 2001 at 10:17:01AM -0700, Brian Pane wrote:
Aaron Bannert wrote:
I'm not sure that the alternative is workable, either.
At the time of the fork, when the child process gets a snapshot of
the parent's memory, it's possible that some thread other than the
From: dean gaudet [EMAIL PROTECTED]
Sent: Tuesday, July 17, 2001 6:15 PM
if you assume that you want some form of notification, but you want to
leave it unspecified because you're not sure what each apr thread will be
used for, then you can make a somewhat generic kill off other threads
[snip]
that would be registered in the parent thread's pool -- and would only
be invoked by the parent thread.
pools let you do this, you don't need the mutexes for it, you just have to
be explicit about parallelism. (combine that with a root pool per thread
and then we can remove
From: Aaron Bannert [EMAIL PROTECTED]
Sent: Tuesday, July 17, 2001 6:41 PM
[snip]
that would be registered in the parent thread's pool -- and would only
be invoked by the parent thread.
pools let you do this, you don't need the mutexes for it, you just have to
be explicit about
I totally agree, but only as a solution in httpd.
no, everywhere.
I also believe that we should provide this [application-specific requirement]
outside of the basic thread support in APR.
Please allow me to use pseudocode:
void * worker_function(void * opaque_application_data)
That architecture was explored in detail by Netscape. It isn't reliable
and slows your web server to a crawl whenever dynamic content is produced.
It should only be used for static file servers and caching gateways, and
people implementing those might as well use an in-kernel server like
I have some use cases that just want a thread. Since no child-pool is
required in this case, it becomes unnecessary overhead (that is currently
broken, as the child-pool is only cleaned in apr_thread_exit() but that
whole thing is screwey).
Again, that is incorrect. The THREAD-pool is
PROTECTED]]
Sent: Friday, July 13, 2001 11:49 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] Problems with MPM threaded
On Sat, Jul 14, 2001 at 12:42:29AM -0400, GUMMALAM,MOHAN
(HP-Cupertino,ex2) wrote:
snip
Have you taken a look at the patch I posted that merges the
POD code
On Sat, Jul 14, 2001 at 12:40:06PM -0700, Aaron Bannert wrote:
APR threads, when created, would now take an additional parameter that
is the mechanism (an sms implementation) by which it should create child
pools. As it is now, the pool that is passed in to apr_thread_create()
serves as the
On Sun, Jul 15, 2001 at 06:49:51PM +0200, Luke Kenneth Casson Leighton wrote:
On Sat, Jul 14, 2001 at 12:40:06PM -0700, Aaron Bannert wrote:
APR threads, when created, would now take an additional parameter that
is the mechanism (an sms implementation) by which it should create child
Fair enough. It's just that in order to opt-out of the child-pool creating
process in apr_thread_create, we're going to have to add a parameter
Why are we so desperate in opting out the child-pool creation?
I don't really have problems with a child pool for each thread. Actually,
it will make
On Sun, Jul 15, 2001 at 07:16:35PM +0200, Sander Striker wrote:
Fair enough. It's just that in order to opt-out of the child-pool creating
process in apr_thread_create, we're going to have to add a parameter
Why are we so desperate in opting out the child-pool creation?
I don't really
Why are we so desperate in opting out the child-pool creation?
I don't really have problems with a child pool for each thread.
Actually,
it will make the dynamic locking a lot easier to implement if it stays.
I have some use cases that just want a thread. Since no child-pool is
On Sat, Jul 14, 2001 at 12:42:29AM -0400, GUMMALAM,MOHAN (HP-Cupertino,ex2) wrote:
I propose the following patch [PATCH A]: It will partially fix the unwanted
child deaths problem (symptoms mentioned in the mails included below). It
fixes the problem by making sure that
On Sat, Jul 14, 2001 at 12:42:29AM -0400, GUMMALAM,MOHAN (HP-Cupertino,ex2) wrote:
[snip]
SOLUTION 1: I plan to temporarily implement a new
apr_lock_acquire_timeout() function, which would cause the threads waiting
on the mutex to give-up after sometime. The piece of code would look
SOLUTION 2: One could use a slightly more _involved_ approach, where the
dying thread could send a signal to its sibling threads, each of which will
then handle that signal with a graceful exit.
How? A thread doesn't have a process id associated with it. And, I'm
curious to whether
On Sat, Jul 14, 2001 at 09:19:17AM -0700, [EMAIL PROTECTED] wrote:
No! The threaded MPM does NOT and was not intended to implement a
thread-only server. It was designed to implement a hybrid thread/process
server. Because we expect both threads and processes, the rest of this
message is
On Sat, 14 Jul 2001, Justin Erenkrantz wrote:
On Sat, Jul 14, 2001 at 09:19:17AM -0700, [EMAIL PROTECTED] wrote:
No! The threaded MPM does NOT and was not intended to implement a
thread-only server. It was designed to implement a hybrid thread/process
server. Because we expect both
By having the possibility of having other children processes, you now
need a mechanism to kill all threads in the same process efficiently.
You'd need to kick them out of the accept mutex, but I'm not seeing
how that's going to happen quickly. -- justin
You need to be able to kill all
On Sat, Jul 14, 2001 at 09:13:08PM +0200, Sander Striker wrote:
The way I see it, each process has a single pool instance as the parent
for all the threads. Resetting or destroying that pool should effectively
kill all threads. What am I missing?
As I see it, the problem is:
[ Platforms with
The way I see it, each process has a single pool instance as the parent
for all the threads. Resetting or destroying that pool should
effectively
kill all threads. What am I missing?
As I see it, the problem is:
[ Platforms with SAFE_ACCEPT == APR_SUCCESS rather than the lock don't
On Sat, Jul 14, 2001 at 12:27:05PM -0700, Justin Erenkrantz wrote:
And, you can't kick the thread out of the mutex acquire (pthread_cancel
or similar strategies don't cancel a mutex operation), so you are
screwed. And, destroying its parent pool does *NOT* destroy the
thread. Look at the
On Sat, Jul 14, 2001 at 09:43:53PM +0200, Sander Striker wrote:
Err, doesn't destruction of the mutex wake everyone up?
Oh, wait, does every process share the same mutex?
Yup. accept_mutex is CROSS_PROCESS. See?
That's the rub. You can't destroy it. Otherwise, you'd screw the
other child
On Sat, Jul 14, 2001 at 12:49:51PM -0700, Aaron Bannert wrote:
Doesn't pthread_mutex_acquire sit in sem_wait() or sigwait()? That'll
let it be cancel()ed.
Nope.
As I posted earlier, man cancellation on Solaris 8 says:
A mutex is explicitly not a cancellation point and should
be
Async cancellation of threads is VERY bad ju-ju. We don't do it because
it causes most, if not all, thread libraries to leak. The cleanups are
called because the child pool is destroyed when all the threads die.
Right, but we're about to kill the processes anyway, so who cares if
it leaks
On Sat, Jul 14, 2001 at 01:19:43PM -0700, Aaron Bannert wrote:
Async cancellation of threads is VERY bad ju-ju. We don't do it because
it causes most, if not all, thread libraries to leak. The cleanups are
called because the child pool is destroyed when all the threads die.
Right, but
On Sat, Jul 14, 2001 at 01:18:04PM -0700, Justin Erenkrantz wrote:
On Sat, Jul 14, 2001 at 12:49:51PM -0700, Aaron Bannert wrote:
Doesn't pthread_mutex_acquire sit in sem_wait() or sigwait()? That'll
let it be cancel()ed.
Nope.
As I posted earlier, man cancellation on Solaris 8 says:
On Sat, Jul 14, 2001 at 01:29:35PM -0700, [EMAIL PROTECTED] wrote:
What you are missing is the history. All of the problems that we are
trying to solve were solved already in the original code. These problem
are solved most easily by using two mutexes, one for keeping only one
process in
On Sat, Jul 14, 2001 at 01:29:35PM -0700, [EMAIL PROTECTED] wrote:
This is why the original code, in apache-apr, written by Manoj back at IBM
used two mutexes. The first was cross-process, the second was
cross-threads. It allowed us to handle this much cleaner. I didn't
realize this had
Ah. Yes, that makes more sense. But, that's not what's there now.
Shall I submit a patch to threaded MPM to do this? -- justin
Please.
This also includes my POD patch. I can separate it out if you don't
want the POD code merged yet. -- justin
Index: threaded.c
The correct fix, as I see it, is to kill off the interprocess
accept lock by removing the possibility of having other processes
in a *threaded* MPM. -- justin
That architecture was explored in detail by Netscape. It isn't reliable
and slows your web server to a crawl whenever dynamic
44 matches
Mail list logo
