-
Hi, sorry for flooding you with issues today :) I have a use case where I run my WSGI app in wsgiserver in a separate process, while the main process runs a test suite. So I currently monkey-patch the # If the caller passed a startup event, monkey patch the server to set it
# when the request handler loop is entered
startup_event = config.get("startup_event")
if startup_event:
def _patched_tick():
server.tick = org_tick # undo the monkey patch
org_tick()
if config["verbose"] >= 1:
print("CherryPyWSGIServer is ready")
startup_event.set()
org_tick = server.tick
server.tick = _patched_tick
try:
server.start()
except KeyboardInterrupt:
if config["verbose"] >= 1:
print("Caught Ctrl-C, shutting down...")
finally:
server.stop() |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments
-
FWIW here's what I do: class WSGIServer(cheroot.wsgi.Server):
"""A custom WSGIServer that prints a line on stderr when it's ready.
Attributes:
_ready: Internal state for the 'ready' property.
_printed_ready: Whether the initial ready message was printed.
"""
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
self._ready = False
self._printed_ready = False
@property
def ready(self):
return self._ready
@ready.setter
def ready(self, value):
if value and not self._printed_ready:
print(' * Running on http://127.0.0.1:{}/ (Press CTRL+C to quit)'
.format(self.bind_addr[1]), file=sys.stderr, flush=True)
self._printed_ready = True
self._ready = value |
Beta Was this translation helpful? Give feedback.
-
Sorry for the delay in response. The way I deal with this sort of situation in general is to avoid interprocess communication altogether and rely on the socket communication to wait on server to bind to the port. For that, I use portend. This approach allows me to disregard the implementation details of a given service.
I recognize that interprocess communication may be more elegant and responsive than to poll a port and time out, but in practice the polling technique is adequate and reliable. I would not object to the server honoring a hook whereby a callback could be made when the server starts, though I'd like to see a proposed implementation before committing to it. I do want to be cautious not to re-implement the higher-level features of CherryPy (like the bus), but to limit the scope to what's an appropriate for a low level interface presented here. Does that help? |
Beta Was this translation helpful? Give feedback.
Sorry for the delay in response.
The way I deal with this sort of situation in general is to avoid interprocess communication altogether and rely on the socket communication to wait on server to bind to the port. For that, I use portend. This approach allows me to disregard the implementation details of a given service.
I recognize that interprocess communication may be more elegant and responsive than to poll a port and ti…