I passed your mail to noury and luc because they got a lot of trouble with the socket code.
On Mar 26, 2013, at 12:12 PM, Holger Hans Peter Freyther <[email protected]> wrote: > Hi, > > I am porting a tooling class that I wrote on GST for my SIP and MGCP code > to Pharo. This class will create a socket and then fork a RX and TX process. > I have some issues with 'stopping' the socket. I have created an example > that shows the issue in Pharo 2.0 and Pharo 1.4 with the pharovm (and to > have more debug output with a re-compiled one). > > > | s rx | > s := Socket newUDP. > rx := [ > [s waitForData. s halt] > on: ConnectionClosed do: [ s halt] > ] fork. > "Wait for the process to hit the readSemaphore" > (Delay forSeconds: 3) wait. > s close. > > > My expectation is that I will get the ConnectionClosed signal or at least > that >>#waitForData will return once the socket is closed. This is based > on reading the comment of >>#waitForData. > > > The Socket>>#waitForData documentation reads like this: > "Wait for data to arrive. This method will block until > data is available or the socket is closed. If the socket is closed > a ConnectionClosed exception will be signaled." > > > I had a look at the socket plugin and the following is happening. First > aio is disabled, the state set to ThisEndClosed, then ::close is called > and in the above case the result is '0' and the following code will be > executed: > > else if (0 == result) > { > /* close completed synchronously */ > SOCKETSTATE(s)= Unconnected; > FPRINTF((stderr, "closeConnection: disconnected\n")); > SOCKET(s)= -1; > } > > > this means that my 'rx' process will happily wait on the readSemaphore > of the Socket and will never be woken up. > > > My question are probably: > > 1.) Is this the intended behavior for Socket>>#close and Socket>>#waitForData? > 2.) How should I terminate my RX process? > > kind regards > holger > > PS: The issue is probably socket specific and not related to UDP. >
