On Wed, 2012-02-22 at 09:06 +1100, Graham Dumpleton wrote:
If you want to be able to control a thread like that from an atexit
callback, you need to create the thread as daemonised. Ie.
setDaemon(True) call on thread.
By default a thread will actually inherit the daemon flag from the
On Tue, Feb 21, 2012 at 8:56 AM, Simon Sapin simon.sa...@exyr.org wrote:
Le 21/02/2012 08:47, Tarek Ziadé a écrit :
Yes, I also think shutting down the server is completely orthogonal to
requests.
If the shutdown callback is next to the application and not registered in
a request, why
Yes, I also think shutting down the server is completely orthogonal to
requests.
CherryPy is using an approach where, indeed, both are orthogonal. Tools
[1], which are similar to middlewares, are dealing with requests whereas
the CherryPy engine [2] is the basis upon which the whole
On Mon, Feb 20, 2012 at 5:03 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
Hello
I need to be able to call a function when the web application shuts down
(SIGTERM/SIGINT) -- the use case is to stop a background thread.
I am currently using signals because it seems to be the most clean way to
On 21 February 2012 18:53, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Tue, Feb 21, 2012 at 2:39 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
...
Overall the best chance of being able to do anything is relying on atexit.
You are though at the mercy of the WSGI hosting mechanism
Le 21/02/2012 09:23, Tarek Ziadé a écrit :
Instead of having to provide two or three objects separately to a
server, how about making the callbacks attributes of the application
callable?
can you show us an example ?
Proposal:
Function-based:
def startup():
return
On 21 February 2012 20:26, Simon Sapin simon.sa...@exyr.org wrote:
Le 21/02/2012 09:23, Tarek Ziadé a écrit :
Instead of having to provide two or three objects separately to a
server, how about making the callbacks attributes of the application
callable?
can you show us an example
On Tue, Feb 21, 2012 at 10:31 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
On 21 February 2012 20:26, Simon Sapin simon.sa...@exyr.org wrote:
Le 21/02/2012 09:23, Tarek Ziadé a écrit :
Instead of having to provide two or three objects separately to a
server, how about
On Tue, Feb 21, 2012 at 10:35 AM, Sylvain Hellegouarch s...@defuze.org wrote:
On Tue, Feb 21, 2012 at 10:31 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
On 21 February 2012 20:26, Simon Sapin simon.sa...@exyr.org wrote:
Le 21/02/2012 09:23, Tarek Ziadé a écrit :
Instead of
Le 21/02/2012 08:56, Simon Sapin a écrit :
Both of these callbacks could be called once per process (aka. space
where requests share memory.)
Sorry, that should be once per interpreter.
--
Simon Sapin
___
Web-SIG mailing list
Web-SIG@python.org
Web
Le 21/02/2012 10:31, Graham Dumpleton a écrit :
You do realise you are just reinventing context managers?
With this 'application' do requests.
Indeed. I didn’t want to go too far from the initial shutdown function
proposal, but actual context managers would be better.
Le 21/02/2012 10:38,
On Tue, Feb 21, 2012 at 10:24 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
...
But I don't think you can guarantee that everything is still up in
memory by
the time atexit gets called,
so you can't really call cleanup code there.
The only thing which is done prior to atexit
On Tue, Feb 21, 2012 at 11:07 AM, Simon Sapin simon.sa...@exyr.org wrote:
...
So a super-set of WSGI that is not just a gateway but also does process
management?
@contextlib.contextmanager
def super_application(server_**infos):
with contextlib.closing(open_**resource()) as resource:
On 21 February 2012 21:41, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Tue, Feb 21, 2012 at 10:24 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
...
But I don't think you can guarantee that everything is still up in
memory by
the time atexit gets called,
so you can't really
On 21 February 2012 21:07, Simon Sapin simon.sa...@exyr.org wrote:
Le 21/02/2012 10:31, Graham Dumpleton a écrit :
You do realise you are just reinventing context managers?
With this 'application' do requests.
Indeed. I didn’t want to go too far from the initial shutdown function
proposal,
Tarek Ziadé ziade.tarek@... writes:
On Tue, Feb 21, 2012 at 10:24 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
...
But I don't think you can guarantee that everything is still up in memory by
the time atexit gets called,
so you can't really call cleanup code there.
The only
On Tue, Feb 21, 2012 at 1:43 PM, Antoine Pitrou solip...@pitrou.net wrote:
Tarek Ziadé ziade.tarek@... writes:
On Tue, Feb 21, 2012 at 10:24 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
...
But I don't think you can guarantee that everything is still up in
memory by
the
On Tue, Feb 21, 2012 at 2:46 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
here's a very simple demo: http://tarek.pastebin.mozilla.org/1489505
There are two typos but the effect remains the same since you are locked
before you reach those lines:
- atexit call worker.stop() instead of
Tarek Ziadé ziade.tarek@... writes:
here's a very simple demo: http://tarek.pastebin.mozilla.org/1489505
There are two typos but the effect remains the same since you are locked
before you reach those lines:
- atexit call worker.stop() instead
of worker.join()
- in worker.stop(), it
On Tue, Feb 21, 2012 at 3:02 PM, Antoine Pitrou solip...@pitrou.net wrote:
...
I find your example convincing. I think that's worth fixing in Python
(e.g. by
offering an atexit() method on Thread objects). Perhaps you can open a bug?
Sure yeah -- Notice that I think it's still a good idea
Simon Sapin simon.sa...@exyr.org a écrit :
Both of these callbacks could be called once per process (aka. space
where requests share memory.)
Sorry, that should be once per interpreter.
--
Simon Sapin
___
Web-SIG mailing list
Web-SIG@python.org
If you want to be able to control a thread like that from an atexit
callback, you need to create the thread as daemonised. Ie.
setDaemon(True) call on thread.
By default a thread will actually inherit the daemon flag from the
parent. For a command line Python where thread created from main
thread
CherryPy provides a bus that allows you to add events to the web server
process. It is specified pretty clearly and CherryPy recently made it available
as a standalone package, Magicbus
(https://bitbucket.org/cherrypy/magicbus/overview). Specifically it allows you
to send events on different
On Mon, Feb 20, 2012 at 8:09 PM, Eric Larson e...@ionrock.org wrote:
CherryPy provides a bus that allows you to add events to the web server
process. It is specified pretty clearly and CherryPy recently made it
available as a standalone package, Magicbus (
oops my examples were broken, should be:
def hello_world_app(environ, start_response):
status = '200 OK' # HTTP Status
headers = [('Content-type', 'text/plain')]
start_response(status, headers)
return [Hello World]
def shutdown(): # or maybe something else as an argument I don't
The standard way to do this would be to define an optional server
extension API supplied in the environ; for example, a
'x-wsgiorg.register_shutdown' function. The wsgi.org wiki used to be the
place to propose these sorts of things for standardization, but it appears
to no longer be a wiki, so
On Mon, 2012-02-20 at 17:39 -0500, PJ Eby wrote:
The standard way to do this would be to define an optional server
extension API supplied in the environ; for example, a
'x-wsgiorg.register_shutdown' function.
Unlikely, AFACIT, as shutdown may happen when no request is active.
Even if this
Le 21/02/2012 01:18, Chris McDonough a écrit :
On Mon, 2012-02-20 at 17:39 -0500, PJ Eby wrote:
The standard way to do this would be to define an optional server
extension API supplied in the environ; for example, a
'x-wsgiorg.register_shutdown' function.
Unlikely, AFACIT, as shutdown
On 21 February 2012 12:03, Simon Sapin simon.sa...@exyr.org wrote:
Le 21/02/2012 01:18, Chris McDonough a écrit :
On Mon, 2012-02-20 at 17:39 -0500, PJ Eby wrote:
The standard way to do this would be to define an optional server
extension API supplied in the environ; for example, a
2012/2/20 Chris McDonough chr...@plope.com
On Mon, 2012-02-20 at 17:39 -0500, PJ Eby wrote:
The standard way to do this would be to define an optional server
extension API supplied in the environ; for example, a
'x-wsgiorg.register_shutdown' function.
Unlikely, AFACIT, as shutdown may
On Mon, 2012-02-20 at 20:54 -0500, PJ Eby wrote:
2012/2/20 Chris McDonough chr...@plope.com
On Mon, 2012-02-20 at 17:39 -0500, PJ Eby wrote:
The standard way to do this would be to define an optional
server
extension API supplied in the environ; for example,
2012/2/21 Chris McDonough chr...@plope.com
On Mon, 2012-02-20 at 20:54 -0500, PJ Eby wrote:
2012/2/20 Chris McDonough chr...@plope.com
On Mon, 2012-02-20 at 17:39 -0500, PJ Eby wrote:
The standard way to do this would be to define an optional
server
On Tue, Feb 21, 2012 at 2:39 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
...
Overall the best chance of being able to do anything is relying on atexit.
You are though at the mercy of the WSGI hosting mechanism shutting
down the process and so the interpreter, in an orderly manner
Le 21/02/2012 08:47, Tarek Ziadé a écrit :
Yes, I also think shutting down the server is completely orthogonal to
requests.
If the shutdown callback is next to the application and not registered
in a request, why not also have the symmetric server start up callback
that would not wait for a
34 matches
Mail list logo
