Sven Van Caekenberghe wrote:
Herby,
In Zn #bleedingEdge
=== Name: Zinc-HTTP-SvenVanCaekenberghe.464 Author: SvenVanCaekenberghe Time: 27 July 2017, 1:10:32.048978 pm UUID: 63589259-ac11-0d00-9153-678c0082c0ce Ancestors: Zinc-HTTP-SvenVanCaekenberghe.460
Make ZnSingleThreadedServer>>#start idempotent (since it called #stop and #stop does a #unregister there was a possible side effect, call #stop: false from #start instead) [thx Herby VojÄÃk] ===
This still does not solve the core problem of #startUp[:] being called twice (apparently) in some situation. But some extra protection won't hurt.
Yes, it will solve it, but mask the bigger problem. OTOH, adding debug output to #start can uncover it for those who want to experiment. Thanks, Herby P.S.: I'll wait with it until I need it, maybe it gets blessed before it it a real problem (on the dev machine, I can have no --headless for a while).
Thx for the suggestion, I hope this solves your curren t issue (remember to load Zn #bleedingEdge).
Sven
On 26 Jul 2017, at 20:19, Herby VojÄÃk<herby@mailbox.sk> wrote:
Hi,
Looking at ZnServer>> start and ZnSingleThreadedServer>> stop (as ZnServer>> stop is #subclassResponsibility), I had the impression they are meant to be idempotent.
The start comment is:
"Start me. I will start listening on my port for incoming HTTP connections. If I am running, I will first stop and thus effectively restart"
The stop comment is:
"Stop me. I will stop listening on my port for incoming HTTP connections. Does nothing when I am not running"
So, it seems like both start and stop try to be safe to be sent twice in a row.
I did a few Transcript prints:
---
1. just stop: is ok.
ZnManagingMultiThreadedServer allInstances do: #stop. ZnServer managedServers do: #unregister. Smalltalk garbageCollect.
(ZnServer on: 4998) stop. (ZnServer on: 4997) stop ; stop.
Transcript show: ZnServer managedServers; cr; show: ZnManagingMultiThreadedServer allInstances; cr.
==>
an IdentitySet() an Array(a ZnManagingMultiThreadedServer(stopped 4998) a ZnManagingMultiThreadedServer(stopped 4997))
---
2. start; stop: is ok.
ZnManagingMultiThreadedServer allInstances do: #stop. ZnServer managedServers do: #unregister. Smalltalk garbageCollect.
(ZnServer on: 4998) start; stop. (ZnServer on: 4997) start; stop; stop.
Transcript show: ZnServer managedServers; cr; show: ZnManagingMultiThreadedServer allInstances; cr.
==>
an IdentitySet() an Array(a ZnManagingMultiThreadedServer(stopped 4998) a ZnManagingMultiThreadedServer(stopped 4997))
---
3. register; start; stop: is ok.
ZnManagingMultiThreadedServer allInstances do: #stop. ZnServer managedServers do: #unregister. Smalltalk garbageCollect.
(ZnServer on: 4998) register; start; stop.
(ZnServer on: 4997) register; start; stop; stop.
Transcript show: ZnServer managedServers; cr; show: ZnManagingMultiThreadedServer allInstances; cr.
==>
an IdentitySet() an Array(a ZnManagingMultiThreadedServer(stopped 4998) a ZnManagingMultiThreadedServer(stopped 4997))
---
4. start: is ok.
ZnManagingMultiThreadedServer allInstances do: #stop. ZnServer managedServers do: #unregister. Smalltalk garbageCollect.
(ZnServer on: 4998) start. (ZnServer on: 4997) start; start.
Transcript show: ZnServer managedServers; cr; show: ZnManagingMultiThreadedServer allInstances; cr.
==>
an IdentitySet() an Array(a ZnManagingMultiThreadedServer(running 4998) a ZnManagingMultiThreadedServer(running 4997))
5. register; start: is not ok.
ZnManagingMultiThreadedServer allInstances do: #stop. ZnServer managedServers do: #unregister. Smalltalk garbageCollect.
(ZnServer on: 4998) register; st
art.
(ZnServer on: 4997) register; start; start.
Transcript show: ZnServer managedServers; cr; show: ZnManagingMultiThreadedServer allInstances; cr.
==>
an IdentitySet(a ZnManagingMultiThreadedServer(running 4998)) an Array(a ZnManagingMultiThreadedServer(running 4998) a ZnManagingMultiThreadedServer(running 4997))
The last case is not idempotent for #start. With one #start, the server is registered, with two #start's, it is not registered.
Shouldn't the last case be idempotent as well?
If it is, it is the bug that should be put into issue tracker?
Herby