> This is great that a new locking implementation will be soon :) Many > thanks. But looking at behavior it is seems more like a harakiri bug > to me. Locks works as expected in usual. (if you kill a process owning > lock others deadlock). Harakiri system seems to be based on fact that > usr2 will iterrupt blocking call and after C level usr2 callback > execution of request handler continues. (which is a bug) > As for the master-governed locking system: anything like that will
SIGUSR2 is only sent to get the current handling request. It is mainly a hack (as we have no other ways to know what a process is doing). After a bit (just to give time to the signal handler to end) SIGKILL is sent. By the way, after a bit of investigation, i came to the conclusion that is better to improve the current code to add a deadlock-detector. Having a user-space logging subsystem would be too slow (up to 200 times in my tests). The new implementation https://projects.unbit.it/uwsgi/browser/master.c#L1548 should get rid of locks retained by dead processes...and should cover all use cases. It has an ultra-tiny race condition if the process dies during pthread_mutex_lock (pretty hard to reach), so it should be pretty solid too. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
