> 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. > >
I strongly hate sysv shared ipc :) Main reason is that each process can leave garbage in the system (garbage that sysadmins forget to clear 99% of the times). uwsgi.lock() (indpendently by the implementation) should work as expected as when a worker (a process) dies the lock is released. By the way enabling robust flag (in multithread modes) could be useful for third-party plugins wanting to spawn threads. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
