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

[Roland McGrath]

> * You can call mach_task_self() anytime you like.  Never deallocate it.

That's right.  Using the macro that is really just a variable and doesn't
diddle refs is not a very clear API, but we inherited it from CMU.

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

> * The same rules as for mach_thread_self() should be followed for
>   mach_host_self().

Leaks is leaks, yes.