bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fork() loses when thread self port's refcount is max'ed out


From: Marcus Brinkmann
Subject: Re: fork() loses when thread self port's refcount is max'ed out
Date: Wed, 16 Oct 2002 20:00:27 +0200
User-agent: Mutt/1.4i

On Tue, Oct 15, 2002 at 04:43:37PM -0400, Roland McGrath wrote:
> > Ok, so we leak in hurd/lookup-retry.c and in sysdeps/mach/getloadavg.c,
> > sysdeps/mach/getsysstats.c, and sysdeps/mach/gettimeofday.c, in glibc.
> 
> Yes.  Given how often gettimeofday might be called, it probably makes sense
> to cache the right once at startup instead of doing the system call every
> time.  If we do that in libc, we could make it a macro in parallel to
> mach_task_self and then not touch any of the users.  Of course, this is
> adding to the hairiness of the situation with another special case that
> violates the normal rule that when returned a right you need to free it.

I wouldn't object.  After all, we can document it in the Mach manual!  ;)

> libpipe perhaps ought to use maptime.  Or perhaps it should just use
> gettimeofday and programs (like all the actual uses of libpipe we have)
> where it makes sense could redefine gettimeofday using maptime to replace
> the libc definition for libpipe et al to see.

Makes sense.  Maybe we could also use this replacement everywhere where we
use maptime (ie libdiskfs et al).
 
> > There are some other leaks which just happen once at initialization.
> 
> That's fine--just like any other resource allocated exactly once and never
> freed until program death.

Yup, although if it is easy to do it makes sense to fix that code as well. 
So that if you copy and paste it or learn from it, you don't copy that into
a place where it's not appropriate.
 
> > Then there are the thread leaks in console-client.c/timer.c,
> > pfinet/timer-emul.c, and a couple of one-time initialization leaks in
> > proc/main.c and term/hurdio.c.  Those can all be changed to
> > hurd_thread_self().
> 
> Those are all cthreads-using programs so there is already no reason not to
> be using hurd_thread_self.

Right.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]