Jason, Python, threads, and signals are always problematic. If I remember correctly the parent thread is the only thread that receives the signal, in order to get the remaining threads to respond to the signal the parent thread needs to kill it's own sub-threads. It's been a while since I have had to do this however. Also, mod_wsgi doesn't use python threads it uses libpthread.so, so I'm also not sure how this plays into the mix either.
Long story short I remember Graham saying that there are issues with using signals. Try and look through old posts for comments about this issue. ~Carl On Mon, Mar 7, 2011 at 11:16 AM, Jason Connor <[email protected]>wrote: > Hi All, > > Some background: I'm writing a large rest server application using web.py > and mod_wsgi. I've deployed the application as a wsgi daemon with 1 process > and multiple threads. This allows me to use a global task queue for running > asynchronous tasks. > > I'm currently trying to implement a server-side debugger by sending a > signal to the wsgi application (sigusr2). I've turned off the signal, stdin, > and stdout restrictions (WSGIRestrict(Signal|Stdin|Stdout) Off). I've setup > a signal handler in the main thread using an import script. The callback > opens and attaches to 2 named pipes in /tmp. The command line script that > sends the signal also opens the pipes. > > However, once I send the signal, nothing happens. The wsgi application > completely ignores and continues to answer requests. If I don't set the > signal handler, when I deliver the signal the application gets interrupted > and mod_wsgi conveniently restarts it. I'm having a hard time figuring out > what is going on as there is no messages logged by apache or even my app > (I've got logging in the signal handler callback). > > Disclaimer: I've read a few threads in this group on this topic. And I've > made use of > * sending extra http request to try and deliver the signal > * start a background thread that wakes up every so often and then goes > back to sleep to trigger the signal delivery > > Any comments by anyone with experience delivering signals to a wsgi daemon > process are welcome. I'm finally out of ideas and would love a new angle to > attack this problem from. > > Thank you, > Jason L Connor > > -- > 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. > -- ------------------------------------------------------------------------------- Carl J. Nobile (Software Engineer) [email protected] ------------------------------------------------------------------------------- -- 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.
