Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
ENH: webagg: Handle ioloop shutdown correctly #6334
Conversation
mdboom
added the
needs_review
label
Apr 25, 2016
|
The AppVeyor error was caused by one of the builds failing to download Miniconda correctly. |
tacaswell
added this to the
2.1 (next point release)
milestone
Apr 26, 2016
|
wouldn't it be simpler to just set If we are going to install a signal handler we need to capture the current handler, call it as part of our handler and then clean up by restoring the previous handler. |
|
I'm not sure I understand your question. |
|
Can you just add I am somewhat surprised that tornado does not stop it's self on a keyboard interupt |
|
That's what I tried first, but it didn't work. As far as I can tell, this is what happens in that scenario:
Specifically, the problem is that the only correct way to stop the IOLoop is by having it run a callback that triggers its |
|
Correction, that linked code is in a |
|
I suppose we could hack around the problem like this:
I can confirm that this works, ugly as it is. The key is that for the IOLoop to be restartable, it needs to exit in a state where both
This seems like least intrusive change that gets the job done, and apparently it's documented behavior. I'll update the PR to use this now. |
|
Travis failure is unrelated. |
tacaswell
and 1 other
commented on an outdated diff
Apr 29, 2016
|
That makes sense, but I worry that it is going to be very dependent on the internal bits of tornado. I suspect that server people do not understand why you would want to start/stop/restart the server in the same process.... Is it worth trying to get the attention of someone from the tornado project on this? attn @mdboom |
|
I agree that it's treading pretty close to unexpected usage. The docs for
Maybe @bdarnell could clear things up? |
bdarnell
commented
Apr 29, 2016
|
After an exception has escaped from |
|
Fair enough. @perimosocordiae Can you do the signal handling with a context manager? Something like @contextmanager
def signal_int_grabber():
old_sig = signal.signal(signal.SIGINT,
lambda sig, frame: ioloop.add_callback_from_signal(on_shutdown))
try:
yield
finally:
signal.signal(signal.SIGINT, old_sig)
with sig_int_grabber():
ioloop.start() |
|
Sure, pushed and squashed. The |
This other wise looks good to me |
|
Curses, off by one! Fixed and squashed. |
tacaswell
closed this
May 2, 2016
tacaswell
reopened this
May 2, 2016
tacaswell
added needs_review and removed needs_review
labels
May 2, 2016
|
@jenshnielsen Can you review and merge this? Given that you found those issues from the nbagg refactor I take it use use webagg? |
|
This looks good to me. The misunderstanding about SIGINT not actually stopping the server was mine originally, and in fairness I only cared about the whole process stopping and never really considered starting up another server. This looks good to me, but it wouldn't hurt to get @jenshnielsen's opinion as well. |
tacaswell
merged commit 1d81f97
into matplotlib:master
May 10, 2016
tacaswell
removed the
needs_review
label
May 10, 2016
|
@perimosocordiae Thanks! |
perimosocordiae commentedApr 25, 2016
This change correctly triggers the
ioloop.stop()method, allowing the user to callplt.show(), then resume control with a SIGINT, then callplt.show()again.Without this change, any attempt to call
plt.show()after killing the webagg server the first time would result in an error because the ioloop instance hadn't been properly stopped.The motivation for using a signal handler comes from this SO answer, which is the only solution I could find that worked as intended.