OK, then one last thing:
Don't you want to apply the same change in py_uwsgi_grunt(), where you do
another fclose()? I'm talking about this
// close connection on the worker
if (PyTuple_Size(args) == 0) {
fclose(wsgi_req->async_post);
wsgi_req->fd_closed = 1;
}
Thanks for the prompt reply, as always :)
Yaniv
On Thu, Aug 25, 2011 at 6:55 PM, Roberto De Ioris <[email protected]> wrote:
>
> Il giorno 25/ago/2011, alle ore 17:47, Yaniv Aknin ha scritto:
>
> > There must be something here I don't understand then.
> >
> > If the parent will close the connection and do a long running task, and
> the child will return the HTTP response, will the child become a regular
> worker of the master process and will keep serving requests as usual?
> >
>
> Wait, i always call uwsgi.disconnect() but in the parent, as i want him to
> continue serving upcoming requests and the child doing hard work.
>
> But this is not a rule, both are exchangable in the logic (and 99% of the
> time depends on what you want to accomplish).
>
> Your logic is right, and the segfault is caused by the (wrong) fclose() in
> uwsgi_pymodule.c
>
> Apply this fix (simply remove the fclose, and substitute it with the new
> protocol indepndent way) and it should work:
>
>
> http://projects.unbit.it/uwsgi/changeset/1428/plugins/python/uwsgi_pymodule.c
>
> On some glibc versions calling fclose on a NULL will segfault.
>
>
> --
> Roberto De Ioris
> http://unbit.it
> JID: [email protected]
>
> _______________________________________________
> 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
