[Prev] Thread [Next]  |  [Prev] Date [Next]

[modwsgi] Re: multiprocessing + modwsgi? Tom Davis Tue Feb 17 20:00:48 2009


I did as you recommended and got the following output in error_log:

    subprocess pid 30467
    hello grumpy

However, following that were various warnings about signal
registration being ignored, as it attempted to do the rest of the
function (I tacked your code onto the beginning):

    [Tue Feb 17 21:48:32 2009] [warn] mod_wsgi (pid=30467): Callback
registration for signal 15 ignored.

So, it would appear that the child is being spawned/run, but only in
the simplest sense. The mod_wsgi rules seem to make it ignore
signals.  If I add back WSGIRestrictSignal Off, the warnings go away,
but the function still doesn't *do* anything. The purpose of the
target function is to make some http requests (via Twisted) then parse
those requests, which involves running the Twisted reactor (the entire
reason I am spawning a new process; the reactor cannot run within a
mod_wsgi thread). It seems this is causing a problem for some reason.
Obviously the target function is being run, as evidenced by the output
in error_log, but Twisted is having trouble with signaling within it
(at least, that is my only guess). As I said, this only seems to be
affected when running w/ mod_wsgi; any other time the function works

On Feb 17, 10:03 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> 2009/2/18 Tom Davis <[EMAIL PROTECTED]>:
> > I am trying to use multiprocessing within a modwsgi app and am having
> > an issue. At first I was getting errors regarding permissions to use
> > stdout, etc. I fixed these by setting WSGIRestrictStdout,
> > WSGIRestrictStdin, and WSGIRestrictSignal to Off in my conf file. Now
> > I get no errors, but the process doesn't actually run. My usage is
> > quite simple: on a page request, I try something along the lines of:
> >  p = multiprocessing.Process(target=fn, args...)
> >  p.start()
> >  p.join()
> > The target doesn't output anything, but if run properly it should add
> > some records to the database. I tested that it works normally by
> > running the app under the django development server, which doesn't
> > seem to have an issue with multiprocessing. Has anyone encountered
> > this before?
> What does the target function do?
> Try following WSGI script file. Note that for this script you will
> need to look in main Apache error log for output, even if WSGI script
> defined in VirtualHost context and that VirtualHost has its own error
> log. This is because am reseting stdin/stdout/stderr back to original
> values. Take out the WSGIRestrictStdin, WSGIRestrictStdout and
> WSGIRestrictSignal directives you already added.
> from multiprocessing import Process
> import sys, os
> sys.stdin = sys.__stdin__
> sys.stdout = sys.__stdout__
> sys.stderr = sys.__stderr__
> def f(name):
>     sys.stderr.write('subprocess pid %d\n' % os.getpid())
>     sys.stderr.write('hello %s\n' % name)
>     sys.stderr.flush()
> def application(environ, start_response):
>     status = '200 OK'
>     output = 'Hello World!'
>     sys.stderr.write('parent pid %d\n' % os.getpid())
>     sys.stderr.flush()
>     p = Process(target=f, args=('grumpy',))
>     p.start()
>     p.join()
>     response_headers = [('Content-type', 'text/plain'),
>                         ('Content-Length', str(len(output)))]
>     start_response(status, response_headers)
>     return [output]
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