On 18/07/12 23:38, Alan Conway wrote:
On Tue, 2012-07-17 at 09:28 +0200, Toralf Lund wrote:
Hi
Does anyone here receive "published" messages in an application using a
something like a GLib main loop? Or Gtk or Qt? If you do, how exactly do
you integrate the message availability check with the main loop? I was
hoping there would be filedescriptor that had data available whenever
messages have arrived, but can't find anything. So I'm experimenting
with a dual thread setup, where one thread just checks for messages and
notifies the other via a pipe. I'm not quite sure what the best way of
checking is, though... I've also tried doing the check in an idle
handler, which does work, but this approach has certain limitations.
There's no FD that you can add to a poll or select loop so a
That's what I thought.
multi-threaded design is probably the only way to go right now. (I would
like to see something like that in the future.)
Me too.
You have a couple of options for how you wait for messages. You can have
a thread-per-receiver in a loop calling Receiver::fetch(), or have a
thread per session in a loop calling Session::nextReceiver() and then
calling fetch() on that receiver.
Yep. I've experimented with the nextReceiver() approach...
At present there's no way to have a
single thread handle all the traffic on a connection, or to have single
global thread handling all the Qpid traffic. (Those are both interesting
avenues to develop)
You mean, because there is no way to get a Connection to list all its
sessions, or sessions with data, or to get a global list of connections?
As to delivering your messages from the listening thread to the active
thread, one way would be to use a qpid::sys::PollableQueue. This is an
in-memory queue (not corresponding to a Qpid queue) that has an
associated FD that you *can* integrate with poll or select. So the
architecture I imagine is: multiple threads doing blocking receive and
putting the messages on a PollableQueue (maybe more than one) that has
its FD registered with your main loop.
That's interesting. I haven't notice there was such a mechanism.
Definitely worth looking into...
You could use some other inter-thread communication, PollableQueue is
just one I know well and find convenient.
Yes. Another approach I've been testing after I wrote the original post,
is to use an "idle" function with GLib - added via g_idle_add(). This is
set up to handle a single message, then unregister itself, and will be
registered with the message and whatever context data is needed as
argument whenever a message is received by the "receiver" thread (so
there may be several "instances" at a given time.) The trick here is
that idle functions are always executed in the thread running the main
loop, even if they are registered in another one. (This is a tip I
picked up from some other forum on the net...) I'm wondering what the
performance will be like when I receive a large number of messages in a
short time, though, in which case *a lot* of idle functions will be
queued up. It also mans having to make assumptions about the actual main
loop used, which I don't really like; I'm trying to design a messaging
lib which is as general as possible. Using Glib functionality is not
*that* bad, though, in that if will also be picked up by other types of
main loops including the one in Qt4.
- Toralf
Cheers,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
This e-mail, including any attachments and response string, may contain
proprietary information which is confidential and may be legally privileged. It
is for the intended recipient only. If you are not the intended recipient or
transmission error has misdirected this e-mail, please notify the author by
return e-mail and delete this message and any attachment immediately. If you
are not the intended recipient you must not use, disclose, distribute, forward,
copy, print or rely on this e-mail in any way except as permitted by the author.
