Date: Sun, 29 Aug 2010 12:00:24 GMT From: Kostik Belousov <kostikbel@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Message-ID: <201008291200.o7TC0ONu053064@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/131597; it has been noted by GNATS.
From: Kostik Belousov <kostikbel@gmail.com>
To: David Xu <davidxu@freebsd.org>
Cc: bug-followup@freebsd.org, guillaume@morinfr.org,
John Baldwin <jhb@freebsd.org>
Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
Date: Sun, 29 Aug 2010 14:57:56 +0300
--siH5g6X9/kbebbtM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Aug 29, 2010 at 02:55:32PM +0800, David Xu wrote:
> Without the previous signal wrapper patch I posted (I am not sure
> I will use it, because it is too complex), I think there is another way
> to avoid sigprocmask, I have ever written a system call
>=20
> sc_shared_t *schedctl(void);
>=20
>=20
> which returns shared data area between userland and kernel.
> userland code sets a flag in the data area to disable signal delivering.
> when kernel code wants to deliver signal, it also checks the flag, and
> does not deliver signals if the flag is set, then the problem would be=20
> fixed:
> http://people.freebsd.org/~davidxu/schedctl/
>=20
I only skimmed over the (incomplete) change. It seems it has issues
with rfork(). In particular, when shared vm space between two processes
becomes forked.
Also, it is not clear to me what would happen if the shared page paged
out or user mode explicitely unmap(2) the shared region. At least the kernel
mapping should be invalidated, otherwise kernel might modify random memory.
I do not like the idea of using additional non-observable state bits,
in addition to the signal mask, to block the signal delivery. IMHO, it
subverts the signal mechanism, and, in case of memory corruption, makes
debugging too hard.
--siH5g6X9/kbebbtM
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkx6S0QACgkQC3+MBN1Mb4iR0ACgvk00JTKvHNa01CmoJCJCeT+D
8F8An0rCa1Z3ZbLlLgi1UC8ICZCxczv0
=LWTr
-----END PGP SIGNATURE-----
--siH5g6X9/kbebbtM--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008291200.o7TC0ONu053064>