Project Home
Project Home		 Trackers
Trackers		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Community/Discussion/QNX Momentics Community Support/Use of select statement prevents multithreaded resource manager to catch SIGTERM/List of Posts
Forum Topic - Use of select statement prevents multithreaded resource manager to catch SIGTERM: (3 Items)
   
Update
Vincent Wan(deleted)
10/18/2013 1:00 PM
post106076
Use of select statement prevents multithreaded resource manager to catch SIGTERM   
I have noticed that in the context of a multithreaded resource manager, when the select() function is called to wait on 
a file descriptor coming from pipe(), the main thread of the resource manager becomes unable to catch the SIGTERM signal
 when the process is slayed.

To reproduce this issue, I have attached a simple resource manager that calls select() on a fd from pipe() whenever a 
read is performed. The select() call normally timeouts after 0.5 ms (results are the same whether I explicitly unblock 
it or not). After that, if the resource manager process is slayed, the following message shows up:

# ./example_g &
# cat /dev/example
# slay example_g

Process 294931 (example_g) terminated SIGTERM code=0 by process 307220 value=0.

If the example is rebuilt with the select() call commented out, SIGTERM is correctly caught by the main thread, and this
 message is seen instead:

Termination Signal correctly received.

This issue is only seen if select() waits on an unnamed pipe. Other file descriptors do not prevent the main thread from
 catching SIGTERM.

Is this a bug in QNX 6.5.0 SP1, or is there something I am doing wrong?

Thanks for your help.
Attachment: Text example.c 6.41 KB
Sean Boudreau(deleted)
10/18/2013 1:25 PM
post106077
Re: Use of select statement prevents multithreaded resource manager to catch SIGTERM   

The signal is received in both cases, just not by the same
thread.  If multiple threads have the signal unmasked
there's no guarantee which one will receive it.  A thread's
signal mask is inherited so you can mask off sigterm before
creating the threadpool then unmask it in the main.

On Fri, Oct 18, 2013 at 01:00:52PM -0400, Vincent Wan wrote:
> I have noticed that in the context of a multithreaded resource manager, when the select() function is called to wait 
on a file descriptor coming from pipe(), the main thread of the resource manager becomes unable to catch the SIGTERM 
signal when the process is slayed.
> 
> To reproduce this issue, I have attached a simple resource manager that calls select() on a fd from pipe() whenever a 
read is performed. The select() call normally timeouts after 0.5 ms (results are the same whether I explicitly unblock 
it or not). After that, if the resource manager process is slayed, the following message shows up:
> 
> # ./example_g &
> # cat /dev/example
> # slay example_g
> 
> Process 294931 (example_g) terminated SIGTERM code=0 by process 307220 value=0.
> 
> If the example is rebuilt with the select() call commented out, SIGTERM is correctly caught by the main thread, and 
this message is seen instead:
> 
> Termination Signal correctly received.
> 
> This issue is only seen if select() waits on an unnamed pipe. Other file descriptors do not prevent the main thread 
from catching SIGTERM.
> 
> Is this a bug in QNX 6.5.0 SP1, or is there something I am doing wrong?
> 
> Thanks for your help.
> 
> 
> 
> 
> _______________________________________________
> 
> QNX Momentics Community Support
> http://community.qnx.com/sf/go/post106076
> To cancel your subscription to this discussion, please e-mail momentics-community-unsubscribe@community.qnx.com
Vincent Wan(deleted)
10/18/2013 2:13 PM
post106082
Re: Use of select statement prevents multithreaded resource manager to catch SIGTERM   
Thanks Sean for your quick response. You are awesome - that was right on.

Best regards,
Vincent

> 
> The signal is received in both cases, just not by the same
> thread.  If multiple threads have the signal unmasked
> there's no guarantee which one will receive it.  A thread's
> signal mask is inherited so you can mask off sigterm before
> creating the threadpool then unmask it in the main.
> 
> On Fri, Oct 18, 2013 at 01:00:52PM -0400, Vincent Wan wrote:
> > I have noticed that in the context of a multithreaded resource manager, when
>  the select() function is called to wait on a file descriptor coming from 
> pipe(), the main thread of the resource manager becomes unable to catch the 
> SIGTERM signal when the process is slayed.
> > 
> > To reproduce this issue, I have attached a simple resource manager that 
> calls select() on a fd from pipe() whenever a read is performed. The select() 
> call normally timeouts after 0.5 ms (results are the same whether I explicitly
>  unblock it or not). After that, if the resource manager process is slayed, 
> the following message shows up:
> > 
> > # ./example_g &
> > # cat /dev/example
> > # slay example_g
> > 
> > Process 294931 (example_g) terminated SIGTERM code=0 by process 307220 value
> =0.
> > 
> > If the example is rebuilt with the select() call commented out, SIGTERM is 
> correctly caught by the main thread, and this message is seen instead:
> > 
> > Termination Signal correctly received.
> > 
> > This issue is only seen if select() waits on an unnamed pipe. Other file 
> descriptors do not prevent the main thread from catching SIGTERM.
> > 
> > Is this a bug in QNX 6.5.0 SP1, or is there something I am doing wrong?
> > 
> > Thanks for your help.
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 
> > QNX Momentics Community Support
> > http://community.qnx.com/sf/go/post106076
> > To cancel your subscription to this discussion, please e-mail momentics-
> community-unsubscribe@community.qnx.com
>

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems