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?
And why no exception is thrown when I specify an explicit timeout? Best regards, 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] > -- \ / | | (OvO) | Mikhail Iwanow | (^^^) | Voice: +7 (911) 223-1300 | \^/ | E-mail: [email protected] | ^ ^ | | --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
