RE: Terminating threads in a process, WAS: RE: [PATCH] Problems withMPM threaded
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 to implement if it stays. all threads MUST have their own private pool root. otherwise you're just throwing scalability away in locks. (which is proved by the claim i saw that ian got better performance by defining ALLOC_USE_MALLOC on an 8-way.) -dean
RE: Terminating threads in a process, WAS: RE: [PATCH] Problems withMPM threaded
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 missing? how does a thread kill another thread? -dean
Re: Terminating threads in a process, WAS: RE: [PATCH] Problems withMPM threaded
On Tue, 17 Jul 2001, Aaron Bannert wrote:
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 to implement if it stays.
all threads MUST have their own private pool root.
otherwise you're just throwing scalability away in locks. (which is
proved by the claim i saw that ian got better performance by defining
ALLOC_USE_MALLOC on an 8-way.)
I totally agree, but only as a solution in httpd.
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) {
apr_pool_t *thread_pool;
create_child_pool(thread_pool, global_root_pool);
do_thread_stuff();
cleanup_child_pool(thread_pool);
if (apr_thread_exit_makes_sense_to_call_from_inside_worker_function) {
int rv = APR_SUCCESS;
apr_thread_exit(rv);
}
return NULL;
}
What I mean by this gibberish is that the pool-handling code can exist
completely outside of our thread_creation-type functions in APR. Is there
any reason for APR threads to do more than this (that is, just simple thread
creation)?
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 make that decision on their
own. I see no way to implement that in a thread-safe manner.
So, I would suggest that we approach this problem in another way. My ONLY
goal for APR is to make a library that is useful for cross-platform
development and eases the pain of cross-platform development for
developers. That was the goal when I created APR, and my original test
case was the Apache web server.
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 their own thread pools. That is wasted effort by every APR app.
I would like to see a conclusion to this thread quickly. So, could people
please post their desires quickly, and what they want to see from this.
Ryan
_
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
-
Re: Terminating threads in a process, WAS: RE: [PATCH] Problems withMPM threaded
:) all is not lost. 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 cleanup. so for example, when an httpd thread is created it would register http_thread_cleanup which would use whatever magic global int die_now_please = 1, and release some condition variable, or throw something into a queue / and so on. 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 alloc_mutex and free lists and push the real gnarly problems into the libc malloc where it's probably best solved.) the main problem i see is that there's no easy way to break a thread out of accept(). but folks may want to look at something such as SIGIO, or having a single acceptor thread per process, or ... using kevent (freebsd), rt signals (linux), /dev/poll (solaris), completion ports (nt) which i believe all have other methods of stuffing events into the queues. for legacy systems (which probably don't have native threads to begin with) you can just use SIGTERM like we did in 1.3 and block it everywhere except during accept(). if i were to write a webserver today i'd probably start with a model such as kevent or rt signals and make the rest of the old legacy world emulate that, because those are the way of the future (and the past actually, vms had this model :). i don't care about performance on legacy operating systems. -dean On Tue, 17 Jul 2001, Aaron Bannert wrote: 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 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, Jul 17, 2001 at 01:32:52AM -0700, dean gaudet 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 missing? how does a thread kill another thread? -dean
Re: Terminating threads in a process, WAS: RE: [PATCH] Problems withMPM threaded
On Tue, 17 Jul 2001, Aaron Bannert wrote:
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 to implement if it stays.
all threads MUST have their own private pool root.
otherwise you're just throwing scalability away in locks. (which is
proved by the claim i saw that ian got better performance by defining
ALLOC_USE_MALLOC on an 8-way.)
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) {
apr_pool_t *thread_pool;
create_child_pool(thread_pool, global_root_pool);
now you've got mutexes in global_root_pool. see my performance comment
above.
-dean
RE: Terminating threads in a process, WAS: RE: [PATCH] Problems withMPM threaded
On Sun, 15 Jul 2001, 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 have problems with a child pool for each thread. Actually, it will make the dynamic locking a lot easier to implement if it stays. The reality is that it should stay. The problem we have right now, is that httpd creates a thread-pool, and then APR creates one. So, if httpd didn't create one, and just used the one APR created automatically, this problem would go away completely. Ryan _ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -
Re: Terminating threads in a process, WAS: RE: [PATCH] Problems withMPM threaded
On Sun, 15 Jul 2001, Aaron Bannert wrote: 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 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 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 cleaned whenever the parent pool is cleaned. Yes, there is some extra overhead, but remember that the problem with pools (as the originally existed, and are still implemented in the server), is that you can't have two threads working with the same pool. IF SMS's replace all pools, then that might change. As things stand today though, that hasn't happened, and may not happen quickly. So if apr threads didn't know anything about child-pools, then they would just simply create a thread that called my worker_function(). I could pass in my opaque data to that worker_function(), and do the child-pool creations and destruction right there. I just don't see how child-pool creation MUST be in apr_thread_create() Yes, you could do that, but then EVERYBODY who wanted to create a thread would have to do that, and why are we forcing people to duplicate that code everytime a thread is created? Ryan _ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -
