On Tue, Jun 2, 2015 at 10:48 PM, Roberto De Ioris <[email protected]> wrote:
> > > Thanks, Roberto, installed 2.1 > > > > How can I find out if things like this happen again, what exactly is > > blocking? Those stacktraces don't seem very useful. I would like to see > > some python-level stacktraces, but uwsgi intercepts all signals, so > signal > > handlers registered in the app itself do not work. > > > when using gevent (or generally stack-switching technologies) the common > available debug tools are almost useless. > > If you enable the python tracebacker the harakiri will automatically > trigger it, but under gevent you have a single thread with multiple > stacks. > > There is a trick to access a greenlet frames: you iterate all the python > objects in the heap (gc.get_objects()) and whenever you find a greenlet > object you access its 'gr_frame' field. > I have this code as an HTTP handler, works pretty fast. The problem is, when it's stuck in C code, HTTP does not work. I thought I can register this code as a signal handler, but how do I register a signal handler, that my app intercepts? looks like uwsgi intercepts all signals, and I can't bind it to USR1 or smth. > > This is slow as hell, so including in uWSGI would be a bad idea. > > Luckily, blocking parts are generally i/o related, so the c traceback you > currently get (with the harakiri-verbose) could be enough for spotting > problems > > -- > Roberto De Ioris > http://unbit.com > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
