From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 8 10:27:30 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98CEB106568F for ; Thu, 8 Oct 2009 10:27:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 171C48FC1C for ; Thu, 8 Oct 2009 10:27:29 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n98ARP6j044513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Oct 2009 13:27:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n98ARPJJ035854; Thu, 8 Oct 2009 13:27:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n98ARPBV035853; Thu, 8 Oct 2009 13:27:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 8 Oct 2009 13:27:25 +0300 From: Kostik Belousov To: Vlad Galu Message-ID: <20091008102725.GH2259@deviant.kiev.zoral.com.ua> References: <6300771b0910071753s6580c099i8c348824a6fe1a72@mail.gmail.com> <20091008100209.GG2259@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MT9P10dJYE2MyE4L" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Stephen Hocking , hackers@freebsd.org Subject: Re: sigwait - differences between Linux & FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 10:27:30 -0000 --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 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--