[Openmcl-devel] A bug and a quick fix
CRLF0710
crlf0710 at gmail.com
Wed Dec 7 20:07:00 PST 2011
2011/12/8 Gary Byers <gb at clozure.com>:
> but I saw the crash when
> running under the standard Windows commmand interpreter (and probably
> would have if I'd just double-clicked on wx86cl.exe and run in a
> console.) I have no idea what exactly causes the crash if this
Yeah, and this problem is especially critical if you have deployed your program
with ccl::save-application and sent it to others. When they try to
close it. BANG~ :)
> Your fix below will make CCL act as if it got a SIGQUIT signal and
> it'll try to quit in a somewhat orderly fashion (closing files and
> running other cleanups first.) That seems reasonable, but it's probably
> not totally unreasonable to just call _exit() or the Windows equivalent
> in that case.
well, i think that is the default behavior. Actually Windows will just
try to quit the application if you do nothing there (return FALSE).
if you call TerminateProcess there, of course CCL will quit
immediately, but may cause data loss in case there are unflushed
streams or things like that.
if you call _exit() or EndProcess there. . I don't think that is very
different from the default behavior. You see, when windows try to
close the application itself, the exception with AUX_TCR = NULL will
be raised (Why is the exception raised anyway...). Maybe it won't
raise a exception, maybe it will. I don't know. Maybe you can give it
a test?
But i think the signal approach is more natural, because that's what
we are already doing for Ctrl-C event. (We're adding support for
Ctrl-Break, Ctrl-Close, Logoff and Shutdown, doesn't have to be this
signal, SIGQUIT, SIGTERM, SIGKILL, or anything like that is just ok,
only if it is handled properly by CCL.)
--
Wir müssen wissen; wir werden wissen!
CrLF.0710
More information about the Openmcl-devel
mailing list