Date: Sat, 13 Jul 2013 20:00:01 GMT From: Konstantin Belousov <kostikbel@gmail.com> To: freebsd-threads@FreeBSD.org Subject: Re: threads/180496: clock_gettime() does not return CPU-time for zombie processes Message-ID: <201307132000.r6DK01sg029857@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR threads/180496; it has been noted by GNATS. From: Konstantin Belousov <kostikbel@gmail.com> To: Petr Salinger <Petr.Salinger@seznam.cz> Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: threads/180496: clock_gettime() does not return CPU-time for zombie processes Date: Sat, 13 Jul 2013 22:50:03 +0300 --E/fwm3itKUspkPYj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 12, 2013 at 10:59:51PM +0200, Petr Salinger wrote: > > Please try this. The clock_gettime() call on zombie clock worked > > for me. >=20 > Perfect. Many thanks. >=20 >=20 > > Note that the check for clock_getres() on the reapped process clock > > failed since we do not check for pid validity, all processes has > > the same clock. I do not see much sense in adding the useless check. >=20 > I agree that such check is technically useless. > I cannot imagine usage of such restriction. >=20 > The only reason of this check is wording of POSIX standard in > http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.ht= ml >=20 > "The clock_getres(), clock_gettime(), and clock_settime() functions shall= =20 > fail if: > [EINVAL] > The clock_id argument does not specify a known clock." I could argue that the clock_id for the reapped pid is/was known. Anyway, due to our implementation of the clock ids, the id is not a handle, but rather a pid-like value. The reused pid would suddenly revive the clock. >=20 > But this behaviour can be easily added in userspace wrapper. > Similarly as > " The clock_settime() function shall fail if: > [EINVAL] > The value of the clock_id argument is CLOCK_MONOTONIC." >=20 > The kernel returns EPERM for ordinary user. >=20 >=20 > Would be possible to MFC SYS_clock_getcpuclockid2 > and related kernel changes into STABLE-9 ? stable/9 is frozen for 9.2. I do not think that re would approve merging of the non-critical new feature now. --E/fwm3itKUspkPYj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR4a9qAAoJEJDCuSvBvK1BU+oP/iR4xBn66pOaVZ3hZU1W/FIJ jBp3X9yjI5XKxVoq/pke5A2nVxaojcIL4V7v8QE+Pb90POpQAJM6cVwZjPPQdRG4 YGVQo8hXS9l2IuTbrsNy876ioQ9U3T1G530aJ7/h/tgZ1yJjn6eXDeBuAWaFyLfo nhoBgAV7PQOmaYvH3+qxuRXwZn/RyjorxrQww4eED+IkMuoL6/JFZTNpWuNwqsU2 fcc6HVNM5XyheHUbaBn42R5alBkk7U3FwfS5hoqlRb1K+Ps8axTRveRjfcnS12+H PmXuliW4kgg4S0WX6TB57Jt7gN6SsjjB7ghCfd9dPt4U0XAUFFCbIza6uWuKhOSw f3CTcdTuT0psHIbfl0zucwBY5HJxQgPy0JjtMBuwtdcNizdV2igzl/KzvRzzmSXB udHb9gr7x/29RYSZyPD5Rt55ZT0x8Ll237T1Ea5FRk2Jb33A/VIWs12DLXnoWLF9 xnzUY8VHIAlX0w5vOM3cVbFv0CaJi92oitygxb7Ss60Nv1FSzdQZEeK+gxiKL/EJ DX5NU2MYLlpW4ZYpsbgJE/Tu0qR9cl4Us8v43Ip+uWi/pBHBEJPvkdTJTCYlq63R oAkvi90GyNXbDxHArq2CKgzRG6MqKCIoN+XZOlporXbRXSD2OqRgY7zQ9KKveUH/ lDLHDxHJLEIwE8NMF22v =WSnN -----END PGP SIGNATURE----- --E/fwm3itKUspkPYj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307132000.r6DK01sg029857>