Date: Tue, 16 Sep 2008 21:21:57 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Daniel Eischen <deischen@freebsd.org> Cc: Attilio Rao <attilio@freebsd.org>, Andrey Chernov <ache@nagual.pp.ru>, current@freebsd.org Subject: Re: Is fork() hook ever possible? Message-ID: <20080916182157.GS39652@deviant.kiev.zoral.com.ua> In-Reply-To: <Pine.GSO.4.64.0809161223260.8954@sea.ntplx.net> References: <20080916140319.GA34447@nagual.pp.ru> <BBB443F5-042C-444E-A2F4-592B66FF2003@gid.co.uk> <20080916144502.GA39765@nagual.pp.ru> <3bbf2fe10809160753o7e5e8a78q7c6bd44c02bfd5c2@mail.gmail.com> <20080916150120.GA40087@nagual.pp.ru> <Pine.GSO.4.64.0809161125120.8677@sea.ntplx.net> <20080916160535.GA40676@nagual.pp.ru> <Pine.GSO.4.64.0809161223260.8954@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Fcn+O7u6afXSKWdN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Sep 16, 2008 at 12:50:53PM -0400, Daniel Eischen wrote:
>=20
> [ Trimmed ]
>=20
> On Tue, 16 Sep 2008, Andrey Chernov wrote:
>=20
> >On Tue, Sep 16, 2008 at 11:36:03AM -0400, Daniel Eischen wrote:
> >
> >>Well, you could speed up getpid() by having libc wrap all fork()
> >>variants. The idea is that getpid() would only call __sys_getpid()
> >>the first time it was called and then only after a fork(). It
> >>would return the saved process id for all other cases.
> >
> >Yes, speeding up getpid() by caching its pid is nice idea.
> >But I am completely unaware how to create syscall wrappers inside libc. =
:(
> >I think about something like that:
> >
> >__weak_reference(_fork, fork);
>=20
> I think you'll have to implement it as __fork() in libc, with
> _fork and fork both being weak references to __fork() in libc. The
> thread libraries will have to call __fork() instead of __sys_fork()
> by implementing "fork" as _fork() and providing a weak reference
> from fork to _fork. You can see wait() as an example.
>=20
> Probably rfork() and vfork() will need to be handled as well,
> though I don't think that the thread libraries care about these.
>=20
> >But how it will coexists with the same __weak in thread/thr_fork.c ?
> >Are some threading locks required in this code?
>=20
> I think you can do it without locks. After a fork() you are
> single threaded so you can easily set/clear __cur_thread.
> Otherwise, the worst case is that multiple threads will call
> _sys_getpid() simultaneously the first time, but as long as
> you atomically update __cur_thread, it won't matter - each
> thread will have retrieved the same exact process id so it
> is okay if they all update __cur_thread.
>=20
> pid_t
> __getpid(void)
> {
>=20
> if (__cur_thread !=3D -1)
> return (__cur_thread);
>=20
> atomic_set_32(&__cur_thread, __sys_getpid());
> return (__cur_thread);
> }
> __weak_reference(__getpid, getpid);
> __weak_reference(__getpid, _getpid);
>=20
> Or something like that...
Do not forget about rfork(). Not sure about rfork_thread().
--Fcn+O7u6afXSKWdN
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAkjP+UUACgkQC3+MBN1Mb4iWNwCfcjSyL18xL2QChcJcLtusG7MP
ASEAnjQyH/uoKNYxdTCEt8S6KPKHBPfj
=gJRs
-----END PGP SIGNATURE-----
--Fcn+O7u6afXSKWdN--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080916182157.GS39652>