:)
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
On Tue, Jul 17, 2001 at 06:28:37PM -0500, William A. Rowe, Jr. wrote:
Yes, yes, yes. Can we please split the concept of a heirarchial parent (the
'creator' thread's or process pool, in this case) from the allocation parent
(the actual give me memory for my pool from ... here!) Then we have an
[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
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,
On Tue, Jul 17, 2001 at 04:49:04PM -0700, dean gaudet wrote:
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.
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 *
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
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
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,
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
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,
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
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
From: Justin Erenkrantz [EMAIL PROTECTED]
Sent: Tuesday, July 17, 2001 12:00 PM
On Tue, Jul 17, 2001 at 11:26:55AM -0500, William A. Rowe, Jr. wrote:
But _unless_ they remain rooted to the top level pool, in
apr_process_create
they become orphaned, and their cleanups are never executed.
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 one
On Sun, Jul 15, 2001 at 02:33:54PM -0700, [EMAIL PROTECTED] wrote:
Guys, before you make comments like this, you should really read the code.
First of all, the thread_exit call needs to take in the thread variable.
Without it, platforms like OS/2 can't return values from the thread exit
There is *zero* benefit to having any relationship between the
thread's memory pool and the parent's memory pool. You can't cleanup
the thread from the parent anyway, so trust the thread to cleanup
itself (as well as its pool and any memory allocations). I fail to
see the problem here.
On Sun, 15 Jul 2001, Justin Erenkrantz wrote:
On Sun, Jul 15, 2001 at 02:33:54PM -0700, [EMAIL PROTECTED] wrote:
Guys, before you make comments like this, you should really read the code.
First of all, the thread_exit call needs to take in the thread variable.
Without it, platforms like
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
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
Ah, ok, I'm getting the picture now. Well, for my purposes, the child
pool creation doesn't have to be in apr_thread_create. There doesn't
have to be child pool creation at all. But, I do want the worker fn
to be able to create a child pool from the pool passed into
apr_thread_create. So, we
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
On Sun, 15 Jul 2001, Justin Erenkrantz 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
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.
You'd
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
28 matches
Mail list logo
