Hi all,
I'm in the process of learning pharo. As an exercise I'm implementing a
"Inter-VM Object channel":
- objects serialized/deserialized via Fuel
- bidi channel connects 2 vm's
- sendObject and receiveObject as api
- transport configurable as either Socket or SharedMem (as an
opportunity to learn the threaded FFI stuff)
During the implementation of the server socket side, I stumbled over a
strange behavior when the backlog is set to a value less than 2:
Here is a simplified version of the server side:
listeningSocket := Socket newTCP.
listeningSocket listenOn: 19999 backlogSize: 1. "NOTE the 1 here!"
clientSocket := listeningSocket waitForAcceptFor: 30.
...
When a client connects:
echo Hallo | nc -v 127.0.0.1 19999
listeningSocket waitForAcceptFor: is unblocked and signals an error
which I think is then masked by another error which is:
"SocketError: cannot access socket error code" which is raised from
Socket primSocketError:
Note that no error is signaled as soon as the backlog size is 2 or more.
- Is there a reason for this behavior or is this a bug?
- Is my analysis correct that the original error is hidden by another
error that is raised during handling of the original error?
Regards,
Martin
--
Martin Fischer
Hi all,
I'm in the process of learning pharo. As an exercise I'm implementing a
"Inter-VM Object channel":
- objects serialized/deserialized via Fuel
- bidi channel connects 2 vm's
- sendObject and receiveObject as api
- transport configurable as either Socket or SharedMem (as an
opportunity to learn the threaded FFI stuff)
During the implementation of the server socket side, I stumbled over a
strange behavior when the backlog is set to a value less than 2:
Here is a simplified version of the server side:
listeningSocket := Socket newTCP.
listeningSocket listenOn: 19999 backlogSize: 1. "NOTE the 1 here!"
clientSocket := listeningSocket waitForAcceptFor: 30.
...
When a client connects:
echo Hallo | nc -v 127.0.0.1 19999
listeningSocket waitForAcceptFor: is unblocked and signals an error
which I think is then masked by another error which is:
"SocketError: cannot access socket error code" which is raised from
Socket primSocketError:
Note that no error is signaled as soon as the backlog size is 2 or more.
- Is there a reason for this behavior or is this a bug?
- Is my analysis correct that the original error is hidden by another
error that is raised during handling of the original error?
Regards,
Martin
--
____________________________________
Martin Fischer