Connor,
I have thought of delegating the recv to another thread, but what I
would like to have idealy is to
avoid the loop(while(true)) to ensure minimal use of the cpu
Thank you for your response,
Maki
On Tue, 16 Apr 2013 16:54:50 +0000, Connor Poske wrote:
Maki,
An asynchronous event-listener interface would be a nice convenience,
but wouldn't simply blocking on recv() in another thread suite your
needs?
Just spawn a thread from your main process to do receiving, while
main does whatever other work it needs to do. This way your process
is not blocked.
________________________________________
From: Maki Camara [[email protected]]
Sent: Tuesday, April 16, 2013 9:37 AM
To: [email protected]
Cc: [email protected]
Subject: Re: Non blocking receive qpid proton
Yes that's exactly what I'm looking for. Is there any mean to do
that?
Thank you
On Tue, 16 Apr 2013 11:27:20 -0400, Darryl L. Pierce wrote:
On Tue, Apr 16, 2013 at 04:54:15PM +0200, Maki Camara wrote:
THank you rafael,
Sorry, I do not have a good english, I am using messenger, setting
the time out to zero can be useful...
I want my process be notified of the arrival of a new message in
the
incoming queue(like a events...)
As long as this event doesn't occur, I can do another thing.... and
when it occur, I will call messenger.recv(0)...
Is this more clear
You want something more along the lines of registering a listener
type
that's called when a new message arrives, is that it?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
