Hello Roberto.
My application use some shared memory black magic. (it is a legacy code)
For sync i am using python multiprocessing.Semaphore.
And i am a bit concerned about possible deadlock if harakiri going
to happen when one worker holds a lock.
I saw a uwsgi.after_request (did not tried it yet) in a mail list
recently so one can use it to do sem.release() in there.
Łukasz Wróblewski is asking for after_request to get a parameter
on how request was finished: (success, error, harakiri) and i agree
with him that would be really cool feature for cleanup/stats system of
applications.
Thoughts about harakiri and deadlock:
With current implementation of harakiri it is seems master is
sending USR2 to worker that is stucked. Suppose worker is stucked in
time.sleep() then USR2 going to interrupt sleep syscall and call USR2
handler (that will print what a worker is doing into uwsgi log). The
bad thing is that after usr2 signal handler is done execution of
request handler continues and there can be another blocking call
(sleep for example).. and then a master will send sigkill after 1 sec.
The bad thing about continuing request handler execution - that causes
hard (evil) killing of worker if it continues to process request.
Anyway with continuing request handler or not after harakiri on
worker application may be deadlocked in both cases when it uses
uwsgi.lock and multiprocessing.Lock. after_request hook seems to help
a bit (as it will interrupt blocking call) but not much - because if
then in request handler more work to do - it will be killed with
sigkill.
a possible solution (not really cool solution) is to handle harakiri so:
master worker
send usr2
intercepts usr2 & prints current
state to log (as now)
calls after_request (without
continuing request_handeler)
if after_request also blocks
sends usr3
intercepts usr3
for lock in
uwsgi.lock[max_lock]: lock.release(); exit(1)
(althrough this will break mules
waiting on other lock.. there is also possibility that application use
multiple locks)
sends kill
Another (better) possible workaround is to use pthread_mutex and
pthread_mutexattr_setrobust with PTHREAD_MUTEX_ROBUST as uwsgi.lock.
(dont know about performance of rwlock vs pthread and portability )
Hmm also there is SEM_UNDO. Dont know which is better pthread_mutex
of semaphore with SEM_UNDO. (Althrough it seems i can use semanchuk
sysv_ipc with SEM_UNDO right now on linux)
ps.
Hmm according to Stevens mutexes is much faster that sem. need to
benchmark myself.
--
--------------------------------------------
Турнаев Евгений Викторович
+7 906 875 09 43
--------------------------------------------
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
