On 01/13/2015 05:24 PM, Michael Ivanov wrote:
Thtnks for reply,
As regarding my expectations I guess that messenger waits for the
next message using some system call, probably poll or select.
I set empty signal handler for SIGUSR1 and when I want to interrupt
the wait I use pthread_kill to send SIGUSR1. The signal handler
is invoked, I checked this. Usually in such situations any blocked
system call also gets interrupted with EINTR error. Is this not
the case with qpid messenger?
The thread blocking on the call is not the same as the thread(s)
blocking on poll.
And why no exception is thrown when I specify an explicit timeout?
The default behaviour of Session::nextReceiver() is to block
indefinitely until a message is available. I suspect it is that call
that you are blocked on, not the subsequent Receiver::fetch().
As Andrew stated, the usual pattern is to specify the wait time in
nextReceiver() and then have a timeout of 0 in the fetch(), since the
first call will only return when there is a message to fetch.
13.01.2015 20:13, Andrew Stitcher пишет:
On Mon, 2015-01-12 at 22:12 +0300, Michael Ivanov wrote:
Hallo,
I am reading the messages from the queue as follows:
Receiver r(_session.nextReceiver());
Message message(r.fetch(Duration::FOREVER d));
This sequence should be spending its time in the nextReceiver() call,
because it should only return when there is a message. So the
message::fetch() should always have a message to fetch. You can use
message::fetch(0) to ensure that it does not wait at all.
At some moment I want to interrupt the receiver using some signal.
From signal handler I invoke pthread_kill(SIGUSR1, pthread_self())
but fetch is not interrupted. Is it just not possible to interrupt
this function or am I doing something wrong?
Can you explain how you think this should work? It's not clear to me
what you'd even expect to happen. Do you have a SIGUSR1 handler? Is it
being called?
Andrew
---------------------------------------------------------------------
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]
