[zeromq-dev] HWM and sockets blocking while in exceptional state

[Massimiliano della Rovere]

On Mon, Dec 19, 2011 at 18:42, Chuck Remes <cremes.devlist at mac.com> wrote:
>
> On Dec 19, 2011, at 10:34 AM, Massimiliano della Rovere wrote:
>
>> In my tests, I :
>> - run the 2 programs instantiating the sockets on the same machine
>> (read below);
>> - use DEALER sockets for both the sender and the receiver;
>> - set RECVHWM to 1 in the receiver;
>> - set SNDHWM to 1 in the sender;
>> but I successfully manage to send any number of messages from the
>> sender without reading any from the receiver.
>
> I doubt this. You can probably send enough messages to fill the kernel buffers but then it should block. You are probably only testing with a few messages.
>

ok before bind and connects I set:
        self._s.setsockopt(zmq.SNDHWM, 1)
        self._s.setsockopt(zmq.RCVHWM, 1)
        self._s.setsockopt(zmq.SNDBUF, 1)
        self._s.setsockopt(zmq.RCVBUF, 1)

and my message is more than byte long.

>> Now having a both RECVHWM and SENDHWM set to 1, I expected that 1st
>> sent message would fill the "RECVHWM slot", the 2nd sent message would
>> fill the "SENDHWM slot" and a 3rd invocation of send() in the sender
>> would block (it's a DEALER socket, shouldn't it)?
>>
>> The strange thing is that if I use a tcp:// or ipc:// transport, the
>> send() is not blocking, but trying with inproc:// transport the send
>> is (correctly) blocking.
>>
>> Is this difference in behaviour correct? Is the RECVHWM only working
>> with inproc transport?
>
> This is a FAQ. Please read it here:
>
> http://www.zeromq.org/area:faq
>
> inproc works "exactly" because there are no kernel buffers in use.
>

Nothing changed: tcp:// is still "not working exactyl", whilst "inproc://" is.