Well, you should do your utmost best to prevent the situation in the first place (use startup/shutdown behaviour correctly).
I remember I had those problems a lot in the beginning of Zn, especially when running tests that sometimes failed. Have you seen Zn's #isListening ? I think that was written to catch the case you described, but I am not sure it is 100% rock solid. Have you seen the other methods of queries protocol of Socket ? > On 30 Jan 2017, at 18:23, Denis Kudriashov <[email protected]> wrote: > > Hi, > > I remember in past there was some reports about it. And now I was a victim of > this problem which is very difficult to debug. > > Pharo allows to start two listener sockets on same port. You will not see any > error. State of both sockets will be identical. "socket isValid, socket > status" will be always correct for both instances. > You can play with sockets with following code: > (socket := Socket newTCP) > setOption: 'TCP_NODELAY' value: 1; > setOption: 'SO_SNDBUF' value: 4096; > setOption: 'SO_RCVBUF' value: 4096. > socket listenOn: 40424 backlogSize: 32. > > When many listener sockets are created. Only first will receive connections. > So first server will work. But others will not with no way to know why. > > But more dramatical scenario is when first socket becomes collected as > garbage which will destroy it. > In this case You will be completely confusing why your single instance in > image is not working. > Such case is of course some bug in how you manage sockets. But that's the > problem: > It is now impossible to debug such cases. > > Can we fix it? Is it possible to signal error when socket is not really > listen? > > Best regards, > Denis
