[Adam Groszer] >> If I click "Shutdown" on the ServerControlForm.html it does not >> shutdown Zope, but responds with a simple "You shut down the server." >> message in the browser and Zope is still working. >> >> I think the problem lies in the modified ThreadedAsync.
Darn. I'm sure I broke this, when removing layers of apparently unused cruft from LoopCallback.py. Apparently there was voodoo control flow intended here, wherein Zope stuffs a module global into LoopCallback and expects ... well, _something_ ... to happen as a result. I guess it expects "the server to shut down" <wink>. [Stephan Richter] > Oh, that seems strange. However, I propose not to fix the bug, since we will > switch to Twisted in 3.2 and there it should definitely work. I don't think that will help (this is apparently aimed at ZEO, at least in part, and I have no plan to switch ZEO to Twisted). Looks like you added the "voodoo control flow" in rev 3432 of LoopCallback.py (March 2004), so we should figure out what you wanted and how to get there now. The signature of asyncore.loop changed in Python 2.4, and it was hugely evil regardless that LoopCallback monkey-patched asyncore.loop with its own loop function, never invoking Python's asyncore.loop (I shudder to imagine how many days of debugging time were lost by various people wondering why breakpoints and debugging prints in asyncore.loop never triggered). So in ZODB 3.4.1a1, I changed LoopCallback.py's loop() to invoke Python's asyncore.loop instead That way it reproduces the correct loop() signature for the version of Python in use, and stopped magically rendering debug code in Python's asyncore.loop useless. Now I want to stop ZEO from sharing its asyncore socket map with other subsystems using asyncore, and for several reasons. When that happens, Zope will need a different way to tell ZEO to stop. We should think about a sane API for that now, although it looks like a hack is needed to get over the immediate problem. This also seems to affect the Zope 2.8 line (hard to tell for sure -- I don't understand the code intent here), and if so waiting for Zope 3.2 isn't good enough on that count either. Question: was the value of LoopCallback.exit_status used by anything? I've been unable to find any code (in any version of ZODB, Zope, or zdaemon) that *looked* at LoopCallback.exit_status, apart from the internal reference in LoopCallback.loop(). There it only cared whether or not the value was None. Did the distinction between a value of 1 and a value of 2 have any meaning? I'm trying to dream up a sane API here, and the first step is to figure out what the code thought it was doing (before I broke it). Another: did this actually work before? The only place I've found that set LoopCallback.exit_status is zope/app/server/servercontrol.py, and both methods there have "TODO: ... does not work yet" comments (in both Zope and Zope3 SVN trunks). _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
