You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Paul J. Reder" <re...@raleigh.ibm.com> on 2001/04/13 16:32:06 UTC
Need access to apr_sigwait from threaded mpm.
Ryan,
In removing the extra signal thread and having the top level child_main
block on signals, I need access to apr_sigwait from the threaded mpm.
It currently seems to be private to APR. Am I missing something?
If not, what is the preferred solution for APR?
Thanks,
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Need access to apr_sigwait from threaded mpm.
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Friday, April 13, 2001 4:07 PM
> +1 on this code. It is basically right and demonstrates the proper way to sync thread
> exits using pthread calls. Whadda I gotta do to convince ya doubting Thomases...
Implement the Win32 APR branch ;-?
Re: Need access to apr_sigwait from threaded mpm.
Posted by Bill Stoddard <bi...@wstoddard.com>.
+1 on this code. It is basically right and demonstrates the proper way to sync thread
exits using pthread calls. Whadda I gotta do to convince ya doubting Thomases...
Bill
> "William A. Rowe, Jr." wrote:
> >
> > Please don't commit first. Could you describe the API so I can ensure that
> > other non-unix threading implemenations could perform some similar strucutre?
> > I may need to introduce some unix no-ops that have an effect on win/netware.
>
> I am currently testing this, but the code looks like this:
> ... existing child_main code except that "thread" becomes "threads[]" and the
create_thread
> call stores the thread info into the threads array for later join use, then the end of
> child_main becomes...
>
> apr_signal_thread(check_signal);
>
> /* A terminating signal was received. Now join each of the workers to clean them up.
*/
> /* If the worker already exited, then the join frees their resources and returns.
*/
> /* If the worker hasn't exited, then this blocks until they have (then cleans up).
*/
> for (i = 0; i < ap_threads_per_child; i++) {
> apr_thread_join(&rv, threads[i]);
> }
>
> free (threads);
> /* The function check_signal just returns 0/1. I doesn't call
*/
> clean_child_exit(0); /* just_die now so that the above joining can happen. This
*/
> } /* means that i need to call clean_child_exit here...
*/
>
> Hopefully this will work for you since it uses apr calls (unless they aren't implemented
> everywhere yet).
>
> Let me know if this is a problem.
>
> --
> Paul J. Reder
> -----------------------------------------------------------
> "The strength of the Constitution lies entirely in the determination of each
> citizen to defend it. Only if every single citizen feels duty bound to do
> his share in this defense are the constitutional rights secure."
> -- Albert Einstein
>
Re: Need access to apr_sigwait from threaded mpm.
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
"William A. Rowe, Jr." wrote:
>
> Please don't commit first. Could you describe the API so I can ensure that
> other non-unix threading implemenations could perform some similar strucutre?
> I may need to introduce some unix no-ops that have an effect on win/netware.
I am currently testing this, but the code looks like this:
... existing child_main code except that "thread" becomes "threads[]" and the create_thread
call stores the thread info into the threads array for later join use, then the end of
child_main becomes...
apr_signal_thread(check_signal);
/* A terminating signal was received. Now join each of the workers to clean them up. */
/* If the worker already exited, then the join frees their resources and returns. */
/* If the worker hasn't exited, then this blocks until they have (then cleans up). */
for (i = 0; i < ap_threads_per_child; i++) {
apr_thread_join(&rv, threads[i]);
}
free (threads);
/* The function check_signal just returns 0/1. I doesn't call */
clean_child_exit(0); /* just_die now so that the above joining can happen. This */
} /* means that i need to call clean_child_exit here... */
Hopefully this will work for you since it uses apr calls (unless they aren't implemented
everywhere yet).
Let me know if this is a problem.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Need access to apr_sigwait from threaded mpm.
Posted by Bill Stoddard <bi...@wstoddard.com>.
> From: "Bill Stoddard" <bi...@wstoddard.com>
> Sent: Friday, April 13, 2001 3:56 PM
>
>
> > I have not reviewed Paul's patch but he and I have discussed it and I am +1 on
concept.
> > Having the main thread join the workers at shutdown ensures that the main thread will
not
> > exit before all the workers have exited. Not unlike what I am doing in the windows
mpm
> > with waitformultipleobject.
>
> Agreed! Note that I'm only concerned that it's sufficiently abstracted to
> be implemented across platforms, not just for unix.
>
> > Our policy is commit the review.
>
> Agreed! Just as long as all recognize the semantics might change a bit :-)
>
Yep, code exists to be changed (or removed :-)
Bill
Re: Need access to apr_sigwait from threaded mpm.
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Friday, April 13, 2001 3:56 PM
> I have not reviewed Paul's patch but he and I have discussed it and I am +1 on concept.
> Having the main thread join the workers at shutdown ensures that the main thread will not
> exit before all the workers have exited. Not unlike what I am doing in the windows mpm
> with waitformultipleobject.
Agreed! Note that I'm only concerned that it's sufficiently abstracted to
be implemented across platforms, not just for unix.
> Our policy is commit the review.
Agreed! Just as long as all recognize the semantics might change a bit :-)
Re: Need access to apr_sigwait from threaded mpm.
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Bill,
I didn't see anywhere in there where he deleted a call to the function
stop_accepting_connections. This is the function that calls the static kill
functions that have the join calls. Perhaps he was just removing dead code.
Stop_accepting_connections isn't static though, so It could have been called
from somewhere else.
I have not found any reference anywhere else to using the join functionality,
nor to creating the threads as joinable. I have looked all through the
httpd-2.0 and apache-2.0 cvs libraries (hadn't gotten to apache-apr yet,
so thanks for saving me the time).
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Need access to apr_sigwait from threaded mpm.
Posted by Bill Stoddard <bi...@wstoddard.com>.
Took a bit of digging but I found out when pthread_join was removed. I think removing
pthread join was a mistake, whatever the reason (reason not clear from the commit
comment). Perhaps the answer is in fdqueue.c...
The change was made by Manoj on the apache-apr tree on May 24, 1999.
1.16 / (download) - annotate - [select for diffs] , Mon May 24 06:18:47 1999 UTC (22
months, 3 weeks ago) by manoj
Bring queued model up-to-date with poll-accept model, for some reason.
This makes the accept threads use poll() on a pipe to discover that it's
time for a child process to die.
Also, since stop_accepting_requests() isn't used anymore (and doesn't
really work anyway), get rid of all references to it in both models.
===================================================================
RCS file: /home/cvs/apache-apr/pthreads/src/main/http_accept.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- apache-apr/pthreads/src/main/http_accept.c 1999/05/24 02:10:26 1.15
+++ apache-apr/pthreads/src/main/http_accept.c 1999/05/24 06:18:47 1.16
@@ -92,8 +92,11 @@
int my_tid = ti->tid;
int sd = ti->sd;
int csd = 0;
+ int srv, ret;
struct sockaddr sa_client;
size_t len = sizeof(struct sockaddr);
+ struct pollfd listenfds[2];
+ char pipe_read_char;
free(ti);
@@ -105,8 +108,17 @@
sock_disable_nagle(sd);
*/
+ listenfds[0].fd = ap_pipe_of_death[0];
+ listenfds[0].events = POLLIN;
+ listenfds[0].revents = 0;
+ listenfds[1].fd = sd;
+ listenfds[1].events = POLLIN;
+ listenfds[1].revents = 0;
+
while ((ap_max_requests_per_child != 0 && requests_this_child > 0) ||
(ap_max_requests_per_child == 0))
+ if (workers_may_exit)
+ break;
(void) ap_update_child_status(my_pid, my_tid, SERVER_ACCEPTING,
(request_rec *) NULL);
/* lock around the accept if necessary */
@@ -123,10 +135,33 @@
csd = -1;
}
else {
- csd = accept(sd, &sa_client, &len);
- requests_this_child--;
- SAFE_ACCEPT(accept_mutex_off(my_tid - ap_threads_per_child));
- SAFE_ACCEPT(intra_mutex_off(my_tid - ap_threads_per_child));
+ for (;;) {
+ srv = poll(listenfds, 2, -1);
+ if (listenfds[0].revents & POLLIN) {
+ /* A process has gotten a signal on the shutdown pipe.
+ * Check if we're the lucky process to die. */
+ ret = read(listenfds[0].fd, &pipe_read_char, 1);
+ if (ret == -1 && errno == EAGAIN) {
+ /* It lost the lottery. It must continue to suffer
+ * through a life of servitude */
+ continue;
+ }
+ else {
+ /* It won the lottery (or something else is very
+ * wrong). Embrace death with open arms. */
+ workers_may_exit = 1;
+ pthread_cond_broadcast(&(csd_queue.not_empty));
+ csd = -1;
+ break;
+ }
+ } else {
+ csd = accept(sd, &sa_client, &len);
+ requests_this_child--;
+ break;
+ }
+ }
+ SAFE_ACCEPT(accept_mutex_off(my_tid - ap_threads_per_child));
+ SAFE_ACCEPT(intra_mutex_off(my_tid - ap_threads_per_child));
}
(void) ap_update_child_status(my_pid, my_tid, SERVER_QUEUEING,
(request_rec *) NULL);
@@ -139,66 +174,10 @@
}
}
- /* Raise SIGWINCH so that all the actions that go with a gradual,
- * graceful shutdown of the process get done.
- *
- * The reason this thread is actually going through the trouble to
- * look up its own process ID is because under Red Hat 5.2, getpid()
- * actually returns the "process ID" of the thread, since threads
- * are just processes that share everything. I hope this is fixed in
- * glibc 2.1 & Linux 2.2. - mvsk */
- kill(ap_scoreboard_image->parent[my_pid].pid, SIGWINCH);
ap_update_child_status(my_pid, my_tid, SERVER_DEAD, (request_rec *) NULL);
return NULL;
}
-
-/* Kill off any worker threads by kicking them out of whatever they are doing
- * and allowing them to see that requests_this_child == 0.
- * It is possible this function could be defined to be NULL in some accept
- * models.
- */
-
-static void kill_workers(void)
-{
- int i;
- int index = find_child_by_pid(getpid());
- parent_score *ss = &ap_scoreboard_image->parent[index];
-
- pthread_cond_broadcast(&(csd_queue.not_empty));
- for (i = 0; i < ss->worker_threads; i++) {
- pthread_join(ap_scoreboard_image->servers[index][i].tid, NULL);
- }
-}
-/* Kill off any acceptor threads by kicking them out of what they are doing
- * and allowing them to see that requests_this_child == 0.
- * It is possible this function could be defined to be NULL in some accept
- * models.
- */
-static void kill_acceptors(pool* pconf)
-{
- listen_rec *lr;
- int i;
- int index = find_child_by_pid(getpid());
- parent_score *ss = &ap_scoreboard_image->parent[index];
-
-
- /* Kick acceptor threads out of accept */
-
- lr = ap_listeners;
- while (lr != NULL) {
- ap_pclosesocket(pconf, lr->fd);
- lr= lr->next;
- }
-
- /* Kick any acceptor out of blocking on a full queue */
- pthread_cond_broadcast(&(csd_queue.not_full));
-
- for (i = ss->worker_threads; i < ss->worker_threads + ss->acceptor_threads; i++) {
- pthread_join(ap_scoreboard_image->servers[index][i].tid, NULL);
- }
-}
-
void accept_parent_init(pool *pconf, int listener_count)
{
SAFE_ACCEPT(accept_mutex_init(pconf, listener_count));
@@ -308,14 +287,6 @@
return csd;
}
-void stop_accepting_connections(pool* pconf)
-{
- requests_this_child = 0;
- /* The two functions to get all of our other threads to die off. */
- kill_acceptors(pconf);
- workers_may_exit = 1;
- kill_workers();
-}
#elif defined(USE_MULTI_ACCEPT)
@@ -481,22 +452,6 @@
}
workers_may_exit = 1;
return -1;
-}
-
-void stop_accepting_connections(pool* pconf)
-{
- int i;
- int index = find_child_by_pid(getpid());
-
- parent_score *ss = &ap_scoreboard_image->parent[index];
-
- requests_this_child = 0;
- workers_may_exit = 1;
-
- for (i = 0; i < ss->worker_threads; i++) {
- pthread_join(ap_scoreboard_image->servers[index][i].tid, NULL);
- }
-
}
#endif
> On Fri, 13 Apr 2001, Bill Stoddard wrote:
>
> > I have not reviewed Paul's patch but he and I have discussed it and I am +1 on
concept.
> > Having the main thread join the workers at shutdown ensures that the main thread will
not
> > exit before all the workers have exited. Not unlike what I am doing in the windows
mpm
> > with waitformultipleobject.
> >
> > Our policy is commit the review.
>
> Yes, but this approach was taken a long time ago, and I am uncomfortable
> going back to it until we know why it was removed back then.
>
> Ryan
>
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
Re: Need access to apr_sigwait from threaded mpm.
Posted by rb...@covalent.net.
On Fri, 13 Apr 2001, Bill Stoddard wrote:
> I have not reviewed Paul's patch but he and I have discussed it and I am +1 on concept.
> Having the main thread join the workers at shutdown ensures that the main thread will not
> exit before all the workers have exited. Not unlike what I am doing in the windows mpm
> with waitformultipleobject.
>
> Our policy is commit the review.
Yes, but this approach was taken a long time ago, and I am uncomfortable
going back to it until we know why it was removed back then.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Need access to apr_sigwait from threaded mpm.
Posted by Bill Stoddard <bi...@wstoddard.com>.
I have not reviewed Paul's patch but he and I have discussed it and I am +1 on concept.
Having the main thread join the workers at shutdown ensures that the main thread will not
exit before all the workers have exited. Not unlike what I am doing in the windows mpm
with waitformultipleobject.
Our policy is commit the review.
Bill
----- Original Message -----
From: "William A. Rowe, Jr." <ad...@rowe-clan.net>
To: <ne...@apache.org>
Sent: Friday, April 13, 2001 1:55 PM
Subject: Re: Need access to apr_sigwait from threaded mpm.
> Please don't commit first. Could you describe the API so I can ensure that
> other non-unix threading implemenations could perform some similar strucutre?
> I may need to introduce some unix no-ops that have an effect on win/netware.
>
> ----- Original Message -----
> From: "Paul J. Reder" <re...@raleigh.ibm.com>
> To: <ne...@apache.org>
> Sent: Friday, April 13, 2001 11:19 AM
> Subject: Re: Need access to apr_sigwait from threaded mpm.
>
>
> > Ryan,
> >
> > Sorry, I missed your commit. The commit you made to the threaded mpm is
> > insufficient. I tested that level of fix (not identical, but close). This
> > still allows the main child_main process to exit (with signal from
> > perform_idle_server_maintenance) and leave orphaned threads.
> >
> > I am currently testing a fix that creates the threads as joinable and then
> > after a received signal the child_main process joins to each of the threads
> > to make sure they are all gone before it exits. Unless there is some concern
> > with this I will commit this extension to your work after I have finished
> > testing it.
> >
> > --
> > Paul J. Reder
> > -----------------------------------------------------------
> > "The strength of the Constitution lies entirely in the determination of each
> > citizen to defend it. Only if every single citizen feels duty bound to do
> > his share in this defense are the constitutional rights secure."
> > -- Albert Einstein
> >
>
Re: Need access to apr_sigwait from threaded mpm.
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
Please don't commit first. Could you describe the API so I can ensure that
other non-unix threading implemenations could perform some similar strucutre?
I may need to introduce some unix no-ops that have an effect on win/netware.
----- Original Message -----
From: "Paul J. Reder" <re...@raleigh.ibm.com>
To: <ne...@apache.org>
Sent: Friday, April 13, 2001 11:19 AM
Subject: Re: Need access to apr_sigwait from threaded mpm.
> Ryan,
>
> Sorry, I missed your commit. The commit you made to the threaded mpm is
> insufficient. I tested that level of fix (not identical, but close). This
> still allows the main child_main process to exit (with signal from
> perform_idle_server_maintenance) and leave orphaned threads.
>
> I am currently testing a fix that creates the threads as joinable and then
> after a received signal the child_main process joins to each of the threads
> to make sure they are all gone before it exits. Unless there is some concern
> with this I will commit this extension to your work after I have finished
> testing it.
>
> --
> Paul J. Reder
> -----------------------------------------------------------
> "The strength of the Constitution lies entirely in the determination of each
> citizen to defend it. Only if every single citizen feels duty bound to do
> his share in this defense are the constitutional rights secure."
> -- Albert Einstein
>
Re: Need access to apr_sigwait from threaded mpm.
Posted by Greg Ames <gr...@remulak.net>.
"Paul J. Reder" wrote:
>
> The problem seems to be
> the window at the end of the worker_thread after is has decremented and
> released the mutex and before it exits. I am seeing cases where the child_main
> process thinks that worker_thread_count == 0, but threads haven't exited
> yet. If child_main exits, then threads are orphaned.
Thanks for the explanation. That makes sense finally. I was beginning
to think that the PTHREAD_CREATE_DETACHED code in the Linux kernel was
broken.
Greg
Re: Need access to apr_sigwait from threaded mpm.
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
rbb@covalent.net wrote:
> Okay, that makes sense. Synchronization is a real PITA. I still want to
> understand why the join stuff was removed before we put it back in though.
> I believe that logic was in either mpmt_pthread.c a while ago, or it was
> from back when Apache 2.0 was called apache-apr.
I will look through the libs in cvs. I was looking through htpd-2.0 and didn't
see it. I didn't realize you were talking that far back.
Test is still running (almost 3 hours of heavy abuse so far).
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Need access to apr_sigwait from threaded mpm.
Posted by Bill Stoddard <bi...@wstoddard.com>.
I don;t recall the join ever being done during shutdown. I am reasonably certain that what
Paul is doing is the right thing to do.
Bill
----- Original Message -----
From: <rb...@covalent.net>
To: <ne...@apache.org>
Sent: Friday, April 13, 2001 4:37 PM
Subject: Re: Need access to apr_sigwait from threaded mpm.
>
> > > We had the join logic in the code for a while, and we removed it at some
> > > point, although I can't remember why. Please take a look in the CVS logs.
> > > I am a bit busy today, becuase Covalent is moving offices (need more
> > > space), so I am having a hard time actually doing work right now. The
> > > easiest way to do this in my mind, though, is to have each thread
> > > decrement a counter as it dies. The core knows how many threads it has,
> > > so we know when they have all died.
> >
> > This is what the code currently does. worker_thread increments/decrements
> > the worker_thread_count variable inside a mutex. The problem seems to be
> > the window at the end of the worker_thread after is has decremented and
> > released the mutex and before it exits. I am seeing cases where the child_main
> > process thinks that worker_thread_count == 0, but threads haven't exited
> > yet. If child_main exits, then threads are orphaned. That is the reason
> > that some after-thread-exit processing (like a join) needs to happen.
>
> Okay, that makes sense. Synchronization is a real PITA. I still want to
> understand why the join stuff was removed before we put it back in though.
> I believe that logic was in either mpmt_pthread.c a while ago, or it was
> from back when Apache 2.0 was called apache-apr.
>
> Ryan
>
> >
> > I will look through cvs for the deleted join logic. Was it in the signal.c,
> > the mpms, or somewhere else (you can say you don't remember - just thought
> > I'd ask to save time).
> >
> > Thanks.
> >
> > --
> > Paul J. Reder
> > -----------------------------------------------------------
> > "The strength of the Constitution lies entirely in the determination of each
> > citizen to defend it. Only if every single citizen feels duty bound to do
> > his share in this defense are the constitutional rights secure."
> > -- Albert Einstein
> >
> >
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
Re: Need access to apr_sigwait from threaded mpm.
Posted by rb...@covalent.net.
> > We had the join logic in the code for a while, and we removed it at some
> > point, although I can't remember why. Please take a look in the CVS logs.
> > I am a bit busy today, becuase Covalent is moving offices (need more
> > space), so I am having a hard time actually doing work right now. The
> > easiest way to do this in my mind, though, is to have each thread
> > decrement a counter as it dies. The core knows how many threads it has,
> > so we know when they have all died.
>
> This is what the code currently does. worker_thread increments/decrements
> the worker_thread_count variable inside a mutex. The problem seems to be
> the window at the end of the worker_thread after is has decremented and
> released the mutex and before it exits. I am seeing cases where the child_main
> process thinks that worker_thread_count == 0, but threads haven't exited
> yet. If child_main exits, then threads are orphaned. That is the reason
> that some after-thread-exit processing (like a join) needs to happen.
Okay, that makes sense. Synchronization is a real PITA. I still want to
understand why the join stuff was removed before we put it back in though.
I believe that logic was in either mpmt_pthread.c a while ago, or it was
from back when Apache 2.0 was called apache-apr.
Ryan
>
> I will look through cvs for the deleted join logic. Was it in the signal.c,
> the mpms, or somewhere else (you can say you don't remember - just thought
> I'd ask to save time).
>
> Thanks.
>
> --
> Paul J. Reder
> -----------------------------------------------------------
> "The strength of the Constitution lies entirely in the determination of each
> citizen to defend it. Only if every single citizen feels duty bound to do
> his share in this defense are the constitutional rights secure."
> -- Albert Einstein
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Need access to apr_sigwait from threaded mpm.
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Ryan,
rbb@covalent.net wrote:
> We had the join logic in the code for a while, and we removed it at some
> point, although I can't remember why. Please take a look in the CVS logs.
> I am a bit busy today, becuase Covalent is moving offices (need more
> space), so I am having a hard time actually doing work right now. The
> easiest way to do this in my mind, though, is to have each thread
> decrement a counter as it dies. The core knows how many threads it has,
> so we know when they have all died.
This is what the code currently does. worker_thread increments/decrements
the worker_thread_count variable inside a mutex. The problem seems to be
the window at the end of the worker_thread after is has decremented and
released the mutex and before it exits. I am seeing cases where the child_main
process thinks that worker_thread_count == 0, but threads haven't exited
yet. If child_main exits, then threads are orphaned. That is the reason
that some after-thread-exit processing (like a join) needs to happen.
I will look through cvs for the deleted join logic. Was it in the signal.c,
the mpms, or somewhere else (you can say you don't remember - just thought
I'd ask to save time).
Thanks.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Need access to apr_sigwait from threaded mpm.
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Fri, 13 Apr 2001, Paul J. Reder wrote:
>
> > rbb@covalent.net wrote:
> > > The problem is with the signal handling function. The function we are
> > > using right now is insufficient. We need to have that function make sure
> > > that ensure that all other threads have died. Currently, it just
> > > basically exits, which is wrong.
> > >
> >
> > Oops, I just replied to otherBill with the current code before I saw this note.
> > What convenient way do you suggest for the signal function to know about the
> > list of threads that are supposed to exist. I am pretty new to using pthread
> > stuff, but I didn't see anything in the docs to suggest a way to wait for all
> > kids and I didn't see where the list if kid tids was being kept. The child_main
> > seems to be the only place where that info resides (briefly until overwritten).
> >
> > If you have a better suggestion than the code I showed otherBill, please let
> > me know. I am still testing this code (it takes a while for things to go south).
>
> We had the join logic in the code for a while, and we removed it at some
> point, although I can't remember why. Please take a look in the CVS logs.
> I am a bit busy today, becuase Covalent is moving offices (need more
> space), so I am having a hard time actually doing work right now. The
> easiest way to do this in my mind, though, is to have each thread
> decrement a counter as it dies. The core knows how many threads it has,
> so we know when they have all died.
>
That will not work. Go back and read my previous note on this.
Bill
Re: Need access to apr_sigwait from threaded mpm.
Posted by rb...@covalent.net.
On Fri, 13 Apr 2001, Paul J. Reder wrote:
> rbb@covalent.net wrote:
> > The problem is with the signal handling function. The function we are
> > using right now is insufficient. We need to have that function make sure
> > that ensure that all other threads have died. Currently, it just
> > basically exits, which is wrong.
> >
>
> Oops, I just replied to otherBill with the current code before I saw this note.
> What convenient way do you suggest for the signal function to know about the
> list of threads that are supposed to exist. I am pretty new to using pthread
> stuff, but I didn't see anything in the docs to suggest a way to wait for all
> kids and I didn't see where the list if kid tids was being kept. The child_main
> seems to be the only place where that info resides (briefly until overwritten).
>
> If you have a better suggestion than the code I showed otherBill, please let
> me know. I am still testing this code (it takes a while for things to go south).
We had the join logic in the code for a while, and we removed it at some
point, although I can't remember why. Please take a look in the CVS logs.
I am a bit busy today, becuase Covalent is moving offices (need more
space), so I am having a hard time actually doing work right now. The
easiest way to do this in my mind, though, is to have each thread
decrement a counter as it dies. The core knows how many threads it has,
so we know when they have all died.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Need access to apr_sigwait from threaded mpm.
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
rbb@covalent.net wrote:
> The problem is with the signal handling function. The function we are
> using right now is insufficient. We need to have that function make sure
> that ensure that all other threads have died. Currently, it just
> basically exits, which is wrong.
>
Oops, I just replied to otherBill with the current code before I saw this note.
What convenient way do you suggest for the signal function to know about the
list of threads that are supposed to exist. I am pretty new to using pthread
stuff, but I didn't see anything in the docs to suggest a way to wait for all
kids and I didn't see where the list if kid tids was being kept. The child_main
seems to be the only place where that info resides (briefly until overwritten).
If you have a better suggestion than the code I showed otherBill, please let
me know. I am still testing this code (it takes a while for things to go south).
Thanks,
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Need access to apr_sigwait from threaded mpm.
Posted by rb...@covalent.net.
On Fri, 13 Apr 2001, Paul J. Reder wrote:
> Ryan,
>
> Sorry, I missed your commit. The commit you made to the threaded mpm is
> insufficient. I tested that level of fix (not identical, but close). This
> still allows the main child_main process to exit (with signal from
> perform_idle_server_maintenance) and leave orphaned threads.
>
The problem is with the signal handling function. The function we are
using right now is insufficient. We need to have that function make sure
that ensure that all other threads have died. Currently, it just
basically exits, which is wrong.
Ryan
> I am currently testing a fix that creates the threads as joinable and then
> after a received signal the child_main process joins to each of the threads
> to make sure they are all gone before it exits. Unless there is some concern
> with this I will commit this extension to your work after I have finished
> testing it.
>
> --
> Paul J. Reder
> -----------------------------------------------------------
> "The strength of the Constitution lies entirely in the determination of each
> citizen to defend it. Only if every single citizen feels duty bound to do
> his share in this defense are the constitutional rights secure."
> -- Albert Einstein
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Need access to apr_sigwait from threaded mpm.
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Ryan,
Sorry, I missed your commit. The commit you made to the threaded mpm is
insufficient. I tested that level of fix (not identical, but close). This
still allows the main child_main process to exit (with signal from
perform_idle_server_maintenance) and leave orphaned threads.
I am currently testing a fix that creates the threads as joinable and then
after a received signal the child_main process joins to each of the threads
to make sure they are all gone before it exits. Unless there is some concern
with this I will commit this extension to your work after I have finished
testing it.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Need access to apr_sigwait from threaded mpm.
Posted by rb...@covalent.net.
Paul,
this work has already been committed. apr_sigwait is a private function,
because it is completely non-portable. The solution was to remove the
apr_create_thread call from the signal thread. We now just have a
function that programs call to block on signals. They provide a signal
handling function, and it gets called. All of the threaded MPMs currently
have the main thread blocking on signals. I committed the work yesterday.
Ryan
On Fri, 13 Apr 2001, Paul J. Reder wrote:
> Ryan,
>
> In removing the extra signal thread and having the top level child_main
> block on signals, I need access to apr_sigwait from the threaded mpm.
> It currently seems to be private to APR. Am I missing something?
> If not, what is the preferred solution for APR?
>
> Thanks,
>
> --
> Paul J. Reder
> -----------------------------------------------------------
> "The strength of the Constitution lies entirely in the determination of each
> citizen to defend it. Only if every single citizen feels duty bound to do
> his share in this defense are the constitutional rights secure."
> -- Albert Einstein
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------