>> Please, do check whether everyting works as expected. > > Hm, presumably, some more patching is needed to cover the cases when one > or both hwms/swaps is infinite. Can you possibly do that?
I tried this patch out, and it works as expected. For infinite HWMs, I think it works, depending on what we want the behavior to be. If one side has a finite HWM, and the other an infinite, and we want the finite one to take precedence, then it works: X+0 = X. And two infinite HWMs stay infinite: 0+0=0. That said, the more I think about this, the more I'm not sure about it. With this patch in place, a PULL inproc socket can affect the HWM buffer that's seen by the PUSH socket on the other side. For a TCP connection, it can't: there's an HWM buffer on the PULL side, but since it's a PULL socket, it's ignored. And I don't think that's something that breaking HWM into SNDHWM/RCVHWM would fix, because the PULL socket could still affect the PUSH's SNDHWM by setting its RCVHWM. Am I missing something obvious? Or does the processing need to be aware of the socket types being connected to do the right thing? –doug
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
