I'm not sure what you mean by minimal CPU use. You should never just spin
inside a while loop like that. The recv() call blocks. This does not use CPU.
while(threadCanRun)
{
receiver.get( timeout ) ; //This blocks until timeout expires
}
________________________________________
From: Maki Camara [[email protected]]
Sent: Tuesday, April 16, 2013 10:13 AM
To: [email protected]
Cc: [email protected]; Connor Poske
Subject: RE: Non blocking receive qpid proton
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]
