[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
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to