[Linux][VM][3.2-5] Socket problem 'dataHandler: selected socket would block (why?)'

Ian Piumarta ian.piumarta at inria.fr
Thu Oct 24 12:01:11 UTC 2002

Hi Stephan,

On Wed, 23 Oct 2002, Stephan Rudlof wrote:
> I have a difficult socket problem with a client/server app: two Squeak
> instances are communicating over a bidirectional socket, which is used
> permanently.
> The error arises deeply in the system in
>   Squeak-3.2-5/platforms/unix/plugins/SocketPlugin/sqUnixSocket.c
> after some time transferring data back and forth (hundreds to thousands
> sends/receives in both directions) and results in an interrupted connection.
> It seems to be that the implementor of the socket code 

That would be me.

> wonders himself/herself about the err msg
>   'dataHandler: selected socket would block (why?)'

The above indicates that:

0.  Squeak polled for i/o by calling the aio polling function
1.  select() subsequently returned _without_ an error condition
2.  a bit was set in the `readable' fdset corresponding to some socket
3.  the socket's dataHandler was called to read from the socket
4.  the dataHandler tried to read () but was told `EWOULDBLOCK'
5.  the dataHandler is now very confused and asks itself `why?'

If I remember correctly the dataHandler then proceeds to assume there's a
problem (and sets it to other-end-closed) because otherwise Smalltalk code
could block forever waiting for something to happen on a damaged socket.

> Has anybody seen this error?
> Has anybody an idea how to hunt the bug further?

Try running your VM with `-notimer' and tell me (either way) if that
helps.  There are a few potential EINTR points in the socket code
(including one in the test for an established connection reached
indirectly from the dataHandler) which maybe should be more intelligent
about how they cope with that condition.

How much hassle is it for you to:

a) reproduce this problem?
b) recompile your VM from source?

If the answers are both `fairly easy' then I could send you some patches
during the course of the afternoon to see if we can eliminate this.  (I'd
get on the case myself except that I'm presenting a seminar tomorrow and
have to finish my presentation slides -- but a little `asynchronous remote
debugging consultancy' would be a welcome distraction. ;)



More information about the Squeak-dev mailing list