thanks! I went with inproc sockets... hope performance is good. will benchmark this.
https://github.com/spesmilo/obelisk/commit/c0882a9b74bcce3cca41e0cf6dab4cb93552ad39 On Tuesday, December 31, 2013 12:44 PM, Bruno D. Rodrigues <[email protected]> wrote: poll on an additional pair of zmq inproc:// sockets ;) On Dec 31, 2013, at 12:41, Matt Connolly <[email protected]> wrote: > Zmq poller can also wake on standard file descriptors (eg unix socket). If > your custom event can write to a unix socket or pipe you might be in luck. > > Cheers > Matt. > >> On 31 Dec 2013, at 4:35 pm, Amir Taaki <[email protected]> wrote: >> >> >> >> I was reading the docs and saw: >> >> "How can I integrate ØMQ sockets with normal sockets? Or with a GUI event >> loop? >> You can use the zmq_poll() function to poll for events on both ØMQ and >> normal sockets. The zmq_poll() function accepts a timeout so if you need to >> poll and process GUI >> events in the same application thread you can set a timeout and >> periodically poll for GUI events. See also the reference documentation." >> >> >> How can I wake up zmq_poll() with a custom event? This seems to solve my >> problems if possible. Then I can create a wakeup to process sends in the >> polling loop. >> >> >> On Tuesday, December 31, 2013 6:14 AM, Amir Taaki <[email protected]> wrote: >> >> Hi! >> >> I have a bit of a design issue. I want to achieve this: >> >> - Software receives a request on a DEALER socket from a ROUTER socket (think >> the worker in paranoid pirate pattern). >> - Request is executed asynchronously in the software. Result is ready inside >> another thread. >> >> - Send it back over the same socket as the receive. >> >> In an ideal world, I'd be polling the socket to receive in one thread, and >> then performing the sends from another. But we cannot use sockets from >> multiple threads - sockets can only be used from one thread. >> >> Currently I have a multi-producer single-consumer lockless queue for sends, >> and then there's an std::condition_variable that's waiting for a signal to >> wake-up and batch process the send queue. Also there's a polling loop for >> receives. All the options I can think of have downsides: >> >> * Use a separate receive and send socket. I'd need some mechanism so that >> the broker (ppqueue) is aware of receive/send socket pairs. Maybe a special >> message for the broker that isn't relayed, but indicates the identity of the >> receive socket. >> >> * Polling then sending reduces the throughput of sends. I've benchmarked >> performance and it's a significant hit. You're essentially penalising sends >> by T microsecs. Sleeping for 0 is not a good idea since CPU usage hits 100%. >> >> * Using the same socket but synchronising access from the send/recv threads >> - ZMQ crashes infrequently when I do this because of triggered asserts. It'd >> be great if I know how to do this safely (maybe by calling some method on >> the socket). >> >> How do I achieve this scenario of 50% random receives and 50% random sends? >> It's not like the classic scenario of a receive, followed by some >> synchronous code path, and then a send (within the same thread). It's not an >> option to wait for requests to finish as I dropped Thrift to use ZMQ because >> of its async ability. >> >> Thanks! >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
