FWIW, I have created issue: http://code.google.com/p/modwsgi/issues/detail?id=176
for this. Have been a bit lax in doing this. I'll treat the inactivity timeout issue separately, if it proves to be an actual problem. Graham 2010/1/26 Graham Dumpleton <[email protected]>: > 2010/1/26 Graham Dumpleton <[email protected]>: >> 2010/1/26 Giel van Schijndel <[email protected]>: >>> On Mon, Jan 25, 2010 at 08:03:44PM +0100, Giel van Schijndel wrote: >>>> On Mon, Jan 25, 2010 at 10:10:42PM +1100, Graham Dumpleton wrote: >>>>> Let me know how it goes. I'll review the code a bit more and perhaps >>>>> also include my other changes to make it more robust. The potential >>>>> problems in it may explain some of the other very rare problems on >>>>> Linux platforms. >>>> >>>> Running it for 30 minutes now. No problems so far. Last time I had >>>> timeout problems immediately, I'm guessing caused by a dead lock which >>>> that patch fixes. >>>> >>>> Either way, I'll leave it running for now until problems arise (in which >>>> case I'll gladly notify you again). >>> >>> Some time later, and now it seems that the daemon crashed. At least I >>> think it must have, considering that it didn't leave anything in the >>> logs, except for timeouts around when the daemon must have gone. No >>> coredump either. >> >> I'll give you an updated patch shortly then which includes the other >> changes I figured are required to make it more robust on platforms >> where conditional wait can actually return even though condition not >> satisfied. > > Revert that prior patch and try this one instead: > > Index: mod_wsgi.c > =================================================================== > --- mod_wsgi.c (revision 1523) > +++ mod_wsgi.c (working copy) > @@ -1314,6 +1314,7 @@ > apr_thread_t *thread; > int running; > int next; > + int wakeup; > apr_thread_cond_t *condition; > apr_thread_mutex_t *mutex; > } WSGIDaemonThread; > @@ -10099,7 +10100,29 @@ > continue; > } > else { > - return apr_thread_cond_wait(thread->condition, thread->mutex); > + apr_status_t rv; > + > + if (thread->wakeup) { > + thread->wakeup = 0; > + > + return APR_SUCCESS; > + } > + > + rv = apr_thread_cond_wait(thread->condition, thread->mutex); > + > + while (rv == APR_SUCCESS && !thread->wakeup) > + rv = apr_thread_cond_wait(thread->condition, thread->mutex); > + > + if (rv != APR_SUCCESS) { > + ap_log_error(APLOG_MARK, WSGI_LOG_CRIT(rv), > + wsgi_server, "mod_wsgi (pid=%d): " > + "Wait on thread %d wakeup condition variable " > + "failed.", getpid(), id); > + } > + > + thread->wakeup = 0; > + > + return rv; > } > } > } > @@ -10130,9 +10153,8 @@ > } > else { > /* > - * Acquire and release the idle worker's mutex > - * to ensure that it's actually waiting on its > - * condition variable > + * Flag that thread should be woken up and then > + * signal it via the condition variable. > */ > > apr_status_t rv; > @@ -10140,6 +10162,9 @@ > APR_SUCCESS) { > return rv; > } > + > + thread->wakeup = 1; > + > if ((rv = apr_thread_mutex_unlock(thread->mutex)) != > APR_SUCCESS) { > return rv; > @@ -10399,6 +10424,8 @@ > WSGIDaemonThread *thread = data; > apr_pool_t *p = apr_thread_pool_get(thd); > > + apr_thread_mutex_lock(thread->mutex); > + > wsgi_daemon_worker(p, thread); > > apr_thread_exit(thd, APR_SUCCESS); > @@ -10679,8 +10706,6 @@ > sleep(5); > } > > - apr_thread_mutex_lock(thread->mutex); > - > /* Now create the actual thread. */ > > thread->id = i; > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
