Comment #3 on issue 4910 by
[hidden email]: Reproducible crash with
Pharo 1.3 + Zn
http://code.google.com/p/pharo/issues/detail?id=4910I would really like to solve this problem. I have described it before, but
here is what I think happens:
- you start the ZnZincServerAdaptor, which implies creating a listener
socket and process
- you test it to see if it is running by doing one or more requests
- this means that at least one connection and worker process are alive
- you save the image
- the server receives a shutdown and stops cleanly
- since this is a ZnMultiThreadedServer and not the experimental
ZnManagingMultiThreadedServer it leaves the connection and the worker
process alone
- you restart the image
- the server receives a startup and starts working
- the worker process is revived and will continue its blocking read for the
next request
- this signals a primitive failed and causes a hang/crash
Now, using the lastest Zn, the primitive failed should be caught and the
connection and worker should be cleaned up silently, unless there is also a
VM problem, but I don't think so.
(It would also be possible to make sure that no open connections are alive,
close the browser that you used, check the Process Monitor)
Another option is to use the experimental ZnManagingMultiThreadedServer
which does track its own connections and cleans them up, which should
result in the worker processes stopping cleanly.
The next code requires the very latest Zinc-Seaside adaptor, you could try:
ZnZincServerAdaptor new
port: 8080;
serverClass: ZnManagingMultiThreadedServer;
start;
yourself
But then you absolutely need this patch:
http://code.google.com/p/pharo/issues/detail?id=4768_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Locked
