[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: coroutine vs threads
- From: Gaspard Bucher <gaspard@...>
- Date: Sun, 17 Jul 2011 17:42:29 +0200
On Sun, Jul 17, 2011 at 4:25 PM, Florian Weimer <email@example.com>
* Gaspard Bucher:
There's an entry about this in the ZeroMQ FAQ:
> I do not think I could use your suggestion of a centralized event loop. What
> happens with zmq requests for example ? These are synchronous calls that
> cannot easily be "posted" as events. I will investigate further to see how I
> could integrate things like "mdns", "zmq" and Qt in a single event loop: a
> single "select" without mutex seems like the obvious choice but I'm not sure
> I can force ZeroConf and ZeroMQ into Qt slavery.
| 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 the
| zmq-camera example for a demonstration.
This doesn't look too good.
But further below, there's this hint:
| Note that there's a way to retrieve a file descriptor from ØMQ
| socket (ZMQ_FD socket option) that you can poll on from version 2.1
| onwards, however, there are some serious caveats when using
| it. Check the documentation carefully before using this feature.
I'm pretty sure that there's a way to do this because it appears to be
a commonly requested ZeroMQ feature.
Do you use any other libraries which involve blocking calls, similar
A lot of stuff are callback based:
* Multicast DNS (Bonjour/ZeroConf)
* WiiMote driver
A solution could be to have these beasts "post" events to the event manager (Qt::Application::postEvent for example), wrapping data as needed. For large data (VideoIn) we create an OpenCV matrix anyway, so that's ok. As for file descriptor based IO, these could be handled with QSocketNotifier so this is easy.
But I am still not sure if the effort is worth the trouble:
* no mutex
* no risk of deadlock (GUI calling callback when locked: Lua --> GUI --> Lua)
* performance gain ?
* higher complexity
* needs an event loop (we don't need one actually if we don't use the GUI)
* data copying across threads (from the callback to the event loop)