[zeromq-dev] Tie Breaker

[Kenneth Adam Miller]

I can't use ZeroMQ for this, because I know if I could this wouldn't be a
problem. But since there are so many systems engineers on the channel and
fundamentally it's what ZMQ aims to solve, I think it's the appropriate
place.

For a scalability benchmark meant to emulate our real world scenario, I
have a cycle created between a producer and a consumer, where the producer
spams a fifo object that the consumer is listening on. The consumer does
some validation work on the data that it was hit with and sends it back out
over a different fifo object that the producer is concurrently listening to
(rather it's a chain of four processes linked in this way).

                 <-   process_echo <-
Producer                                      consumer
                ->    process_echo ->

This works fine from the perspective of the producer, because listening and
writing requires no coordination between threads. But the producer and
echoing processes were written singled threaded, and from the perspective
that it would poll only for input and not for when it writes.

Well, as my testing went along I discovered that I had to make both the
producer and consumer poll on output so that no data could be lost when the
sender goes to send and the fifo isn't being read from fast enough.
(possibly that's wrong)

But using poll on the sender has caused hangups on the system as a whole.
Poll returns for readers, I think, when someone has already written or is
writing. And for writers, when someone is blocking (whether polling or in
read) to read.

But the problem that this solves brings up a different problem: if the
single threaded programs poll to write, then the cycle could deadlock where
every side is polling to write, before even one message makes it fully
round circle.

My thought is, I could break it by making the consumer concurrent in
reading and writing, that way, lockup on send cannot happen, because there
will always be a reader to allow execution to continue in the echo tool and
consumer. But that's hard because the code base is large.

I said all of that just to ask-does anybody have any alternative
suggestions regarding how to approach this exact problem?

All fifo objects are in non-blocking mode.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150728/bd3a3a3b/attachment.htm>