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

[Marcus Brinkmann]

On Sun, Oct 13, 2002 at 05:13:48PM -0400, Roland McGrath wrote:
> > * You should never call mach_thread_self().  If you need to call it,
> >   don't call it a number of times linear to the running time of the
> >   program.  If you follow that rule, you could even get away with
> >   deallocating the port, but if you follow that rule you don't need to
> >   deallocate it, so you shouldn't.
> 
> Um, this is a pretty roundabout way to state: free the refs you create, end
> of story.  Like the mach_task_self_ variable, some libc/libpthread data
> structures have the right already so you can get it with no syscall
> overhead and without adding a ref.  This is fine to do when you know it
> will be live.  The task port you know will always be live, because when
> it's so are you.  The thread port for the running thread you know will be
> live as long as it's running, and that's usually the place that needs it.

Ok ok.  That is quite convincing.
 
> > * The same rules as for mach_thread_self() should be followed for
> >   mach_host_self().
> 
> Leaks is leaks, yes.  

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.

Also in exec/hostarch.c:elf_machine_matches_host, used by check_elf,
libpipe/pipe.c:timestamp (which should probably be replaced by calls
to gettimeofday, really), and in proc/mgt.c:add_tasks.  There are some other
leaks which just happen once at initialization.

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().

Anybody wants to clean those up?  If not I can do that later.

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/