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

[Roland McGrath]

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

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

Yes.  Those are frequent too and could benefit from caching.

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.

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

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