Il giorno 03/mag/2012, alle ore 14:01, Gunnlaugur Thor Briem ha scritto: > From: Roberto De Ioris <[email protected]> > > 1.2 is smarter about disconnected clients. Your request will end as soon as > the client disconnect (no more waste of resources) > > Really? Three questions about that: > > 1. this was an IOError raised in start_response ... that seems to me like it > happens (a) when the app tried to write to the client, not (b) "as soon as" > the client disconnects. Did you mean uwsgi does (a), or does it really do > (b)? How? By a signal?
> > 2. if (b), does that work via nginx too? I.e. as soon as nginx gets the > disconnect, it tells uwsgi, and the worker aborts whatever it's doing? Or > does this happen only when uwsgi serves http itself? > > 3. also if (b), can my python app get a signal about this immediate request > end, that it can use to abort back-end resource use, say a heavy DB query? > Does this require me to run threads/gevent, or could I just > uwsgi.cache_set(os.getpid(), backend_id) whenever I start a possibly heavy > backend query, and then uwsgi would call my callback function > worker_aborted(pid) where I would pull the backend_id out of the uwsgi cache > and tell my backend to abort? > > Or am I misunderstanding completely? :) > I definetely used the wrong words :) As you said, uWSGI knows about client disconnection at the first write()/writev(). In previous versions, apps was not aware of disconnections and failed writes were ignored (you get only a series of SIGPIPE) -- Roberto De Ioris http://unbit.it JID: [email protected] _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
