On Wed, Nov 11, 2009 at 6:10 AM, David Turner <di...@android.com> wrote:
> Probably because Linux essentially delivers signals to random threads. So > the signal handler is called but not in the thread that is doing the > sigsuspend. > You probably need to mask SIGIO in all other threads of your process, which > sucks. > > A better alternative is to try something different. For example, create a > pipe() and have the signal handler send a single byte through write() > into it. Your other thread can be blocked on read()-ing the byte, and this > would work independently of the thread receiving the signal. > Be sure to catch for EINTR during the write() and read() calls though :-) > > Great. I will try using PIPE , instead of sigsuspend() . Thanks, Shankar > On Tue, Nov 10, 2009 at 12:27 PM, fadden <fad...@android.com> wrote: > >> On Nov 9, 10:18 pm, Shankar Ganesh <shankargane...@gmail.com> wrote: >> > Here, SIGIO is received by signal handler, but my user-space process >> (open >> > core decoder node process) is hanged and never wakes-up and hence >> blocked >> > within sigsuspend() . >> > Can anyone throw some ideas if you have faced similar problem ? >> >> I don't quite understand -- you say the process receives the SIGIO, >> but it's hung and never wakes up. If the process is hung, how do you >> know it received the signal? >> >> Are you sure the signal is being delivered to the correct thread >> within the process? >> >> FWIW, the VM uses sigwait() to do something similar. >> >> -- >> unsubscribe: >> android-porting+unsubscr...@googlegroups.com<android-porting%2bunsubscr...@googlegroups.com> >> website: http://groups.google.com/group/android-porting >> > > -- > unsubscribe: > android-porting+unsubscr...@googlegroups.com<android-porting%2bunsubscr...@googlegroups.com> > website: http://groups.google.com/group/android-porting > -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
