Please try the following patch for FreeBSD daemon mode problems with
mod_wsgi 3.X.
It appears that FreeBSD doesn't like a thread mutex being unlocked
from a thread different to the thread it was originally locked by.
This was causing use of a condition variable to fail but error result
wasn't being tested and so code was assuming it had been successful in
being notified that it could precede.
The change moves the locking of the mutex into the actual thread when
it is created.
Reading some of the comments against the problem function in APR am
still not sure the original code I copied is completely robust and it
perhaps should be using additional variable flag to know condition has
in fact been satisfied. My code where I got it working does this, but
have only posted the minimal fix at this point.
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.
Sorry for how long this has taken, I just haven't had much time of
late due to things still needing to be done related to me moving
house. I have been lucky to steal a couple of hours that I have an am
sure to be roasted over the fact my office/study is still a mess. :-)
Graham
Index: mod_wsgi.c
===================================================================
--- mod_wsgi.c (revision 1523)
+++ mod_wsgi.c (working copy)
@@ -10399,6 +10399,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 +10681,6 @@
sleep(5);
}
- apr_thread_mutex_lock(thread->mutex);
-
/* Now create the actual thread. */
thread->id = i;
2010/1/20 Graham Dumpleton <[email protected]>:
> 2010/1/20 Pawel Tyll <[email protected]>:
>> On Jan 20, 4:55 am, Graham Dumpleton <[email protected]>
>> wrote:
>>> The apr_atomic_cas32() function is used in some of the Apache MPM
>>> modules so if it is broken, would expect Apache core to have issues as
>>> well.
>> No problems with apache itself here. Maybe try looking at the calls
>> themselves to double check that you're using them correctly? Oh well,
>> since everything is fine under other OSes, then you probably are.
>
> Except that default Apache on FreeBSD is 'prefork'. The
> apr_atomic_cas32() call is only used in worker MPM. :-)
>
> Know of people have problems with worker MPM on FreeBSD. Maybe for
> prefork the configure options aren't quite the same and so something
> not being compiled in correctly. Checking the object files though, it
> appears to be correctly compile the routines from ia32.c file in apr
> library, so is using Intel instructions.
>
> I'll have to review my code, but it is effectively a copy of something
> similar done in one of the old experimental MPMs for Apache. :-(
>
> Graham
>
--
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.
