From: Bodo S. <bst...@fu...> - 2005-05-18 19:19:38
|
Blaisorblade wrote: > On Tuesday 17 May 2005 12:14, Bodo Stroesser wrote: > >>I didn't have the time to test the patch, but I guess, it won't work. >> >>Maybe, the man pages for sigsuspend are somewhat missleading, saying: >> >> The sigsuspend call temporarily replaces the signal mask for >> the process with that given by mask and then suspends the >> process until a signal is received. > > In fact, I assumed that was correct... > >>Reading the code of sys_sigsuspend() in arch/i386/kernel/signal.c, >>you'll find that it will return to user only, if do_signal() returns 1. >>This will happen, if there was a signal to deliver. Ignored signals >>will not be delivered, so sys_sigsupend will not return on SIGWINCH, >>if SIGWINCH handler is set to SIG_IGN. > > Doh! You're right, actually. > >>So, for UML's winch_handler, there is no difference between pause() >>and sigsuspend(), because sigsuspend's feature of accepting a sigmask >>for use while waiting, in fact isn't needed here as the same mask is >>set already before with sigprocmask(). > > Ok, seems like I'll drop this patch. Thanks for the review. Maybe, we really should use sigsuspend() instead of pause(), but the reason for this isn't to remove the winch_handler. The current loop in winch_thread() might miss a SIGWINCH, if a SIGWINCH comes in while winch_thread() isn't waiting in wait(). So I think, winch_thread() should block all signals including SIGWINCH. In its loop it should call sigsuspend() with a mask as argument, that unblocks SIGWINCH while sigsuspend() waits. I've attached a patch (tested a bit only). Bodo |