[Tim Peters]
>> 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).

[Adam Groszer]
> Yes it did work. That was the quickest way on win32 to shutdown Zope.
> I cannot tell you the exact time when it was working last, but I'm
> sure it was working 1-2 months before.

Current Zope3 head (as of a minute ago) restores the
LoopCallback.exit_status gimmick, and clicking on "Shutdown server"
does stop Zope3 now.  That's one meaning for "actually work".

Based on staring at the code, there are other meanings for "actually
work" that don't:

- "Shutdown server" causes the Python process to exit, almost immediately.
  There's no _controlled_ shutdown here; e.g., sockets aren't closed cleanly,
  files aren't closed, requests in progress are presumably left hanging -- stuff
  like that.

- Putting a non-zero number in the "Shutdown time" box appears to have no
  additional effect.  I'm not sure what "hard" in the page's "If you
specify a time
  of 0 seconds, then the server will do a hard shutdown" intends to say, but
  I'd call its behavior now "hard" (& regardless of how many seconds are

- The "Restart server" button does the same thing as "Shutdown server":  the
  Python process exits almost immediately (and nothing restarts).

None of the above appears to have anything to do with LoopCallback,
though, so if any of that "used to work" but doesn't anymore, there's
a cause outside of the changes I made to LoopCallback.  Best guess is
that the stuff above never "worked" in Zope3, and that's the meaning
of the ""TODO:  ... does not work yet" comments in
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to