Date: Thu, 8 Oct 2009 13:27:25 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Vlad Galu <dudu@dudu.ro> Cc: Stephen Hocking <stephen.hocking@gmail.com>, hackers@freebsd.org Subject: Re: sigwait - differences between Linux & FreeBSD Message-ID: <20091008102725.GH2259@deviant.kiev.zoral.com.ua> In-Reply-To: <ad79ad6b0910080323n76e2c659tadf59bc5f099a182@mail.gmail.com> References: <6300771b0910071753s6580c099i8c348824a6fe1a72@mail.gmail.com> <20091008100209.GG2259@deviant.kiev.zoral.com.ua> <ad79ad6b0910080323n76e2c659tadf59bc5f099a182@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--MT9P10dJYE2MyE4L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 08, 2009 at 01:23:37PM +0300, Vlad Galu wrote: > On Thu, Oct 8, 2009 at 1:02 PM, Kostik Belousov <kostikbel@gmail.com> wro= te: > > On Thu, Oct 08, 2009 at 11:53:21AM +1100, Stephen Hocking wrote: > >> Hi all, > >> > >> In my efforts to make the xrdp port more robust under FreeBSD, I have > >> discovered that sigwait (kind of an analogue to select(2), but for > >> signals rather than I/O) re-enables ignored signals in its list under > >> Linux, but not FreeBSD. The sesman daemon uses SIGCHLD to clean up > >> after a session has exited. Under Linux this works OK, under FreeSBD > >> it doesn't. I have worked around it in a very hackish manner (define a > >> dummy signal handler and enable it using signal, which means that the > >> sigwait call can then be unblocked by it), but am wondering if anyone > >> else has run across the same problem, and if so, if they fixed it in > >> an elegant manner. Also, does anyone know the correct semantics of > >> sigwait under this situation? > > > > ports@ is the wrong list to discuss the issue in the base system. > > > > Solaris 10 sigwait(2) manpage says the following: > > If sigwait() is called on an ignored signal, then the occurrence of the > > signal will be ignored, unless sigaction() changes the disposition. > > > > We have the same behaviour as Solaris, ingored signals are not queued or > > recorded regardeless of the presence of sigwaiting thread. > > >=20 > This is a bit confusing. sigwait(2) says: "The signals specified by > set should be blocked at the time of the call to sigwait()."... Blocked and ignored are different attributes of signal. Ignored means that signal disposition is SIG_IGN, that causes the signal delivery event to be ignored. Blocked means that regardeless of signal disposition, signal is not delivered, but it is recorded somewhere and delivery happen when it unblocked. --MT9P10dJYE2MyE4L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrNvowACgkQC3+MBN1Mb4gtDgCeLIB+Dk3bkR43wmYZDW+/1sNX zloAoIHgaMm0qpUI8dYjePghtPNg6SND =PNY3 -----END PGP SIGNATURE----- --MT9P10dJYE2MyE4L--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091008102725.GH2259>