On Wed, Jul 18, 2001 at 02:53:33PM -0400, Benjamin W. Ritcey wrote:
> As an end-user of apache, I'd like to chime in: please, please, please leave
> the N processes with M threads model available -- "the hypothetical buggy
> 3rd party modules should be fixed rather than hacked around" is fine in
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
AMEN! My goal as a sys admin/web admin is to keep serving pages
during ALL
problems. :) IE the server is up and STAYS up.
Wednesday, July 18, 2001, 2:53:33 PM, Benjamin W. Ritcey wrote:
BWR> As an end-user of apache, I'd like to chime in: please,
[EMAIL PROTECTED]
Subject: 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 c
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
> > 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 serv
> > 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_ap
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
[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
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 threa
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 thr
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
>
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.,
> 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 ap
> 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
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
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 crea
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
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 e
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 Tue,
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
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 bugg
mailto:[EMAIL 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:
>
>
>
> Have you taken a look at th
> > 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 THREA
> > 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 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 real
> 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 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
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 "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 c
> > 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
=
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
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: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
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.
>
> Righ
> 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 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
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: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 t
On Sat, Jul 14, 2001 at 12:10:30PM -0700, [EMAIL PROTECTED] wrote:
> On Sat, 14 Jul 2001, 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
> > 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 l
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 wi
Right, changed the subject line again, the typo was hurting my
eyes and I wouldn't want a thread with that subj. line.
Sorry for reposting.
Justin:
>> By having the possibility of having other children processes, you now
>> need a mechanism to kill all threads in the same process efficiently.
>>
>> 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 kil
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 bo
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
> > 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 wh
-1. The problems detailed in the messages are a misconfigured server, not
a bug in the code. The threaded MPM should count ALL idle threads,
whether they are a part of the process that was just told to die or not.
Any idle threads that are a part of the process that was just told to die
will be
On Sat, Jul 14, 2001 at 01:06:28AM -0700, Aaron Bannert wrote:
> This looks like a job for condition variables. Using condition
> variables you can control exactly when threads get woken up to check
> on the condition. For example, when one thread returns from accept(),
> it can signal another th
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
> some
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 perform_idle_server_
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 perform_idle_server_maintenance() does
not count the threads of the process that recd the POD, in the calcula
51 matches
Mail list logo
