[Top][All Lists]

[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: Roland McGrath
Subject: Re: fork() loses when thread self port's refcount is max'ed out
Date: Sun, 13 Oct 2002 17:13:48 -0400 (EDT)

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

reply via email to

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