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<he...@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
