[Openmcl-devel] process-run-function and mach ports usage

[Wim Oudshoorn]

> I was going to write a longer reply, but I'd already spent a few hours
> looking into this today (seeing some of the same things that you saw
> and reaching some different conclusions), and this is all starting to
> seem too much like the sort of thing where it's said that "if you don't
> stop doing it, you'll go blind."

Yes, the mach_port mechanism in CCL seems to induce blindness.
I stared it for quite a while and never really figuring out where
the increased right count comes from.

> Apple's documentation for mach_thread_self() (see
>
> <http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/osfmk/man/mach_thread_self.html?txt>)

Thank you for the reference to apples man pages.

> This stuff escaped from a lab somewhere; the fact that it's been
> lurching around the countryside frightening villagers as long as it
> has is pretty sad.

You don't seem to really like mach. From what I read it seems
quite ok.  It is a shame I haven't found a very good manual
with enough detail to know what exactly is going on.

> You're right that this needs
> to be addressed: I don't care as much as I might about trying to
> create millions of trivial threads as fast as they can, but I do
> care about long-lived processes being able to create large numbers
> of threads over a long period of time without having their performance
> degrade.

This is how I stumbled upon it.  My hunchentoot server started to become
slower and slower (this is not helped by the fact that even if
no requests are coming in, hunchentoot creates about 1-2 threads a second.)


> It -does- seem to be practical to try to ensure that the last thing
> that a thread does (this would be in
> thread_manager.c:shutdown_thread_tcr(),
> which does most of the deallocation of thread-private resources) is to
> ensure that the kernel port's send right's reference count is exactly 1.
> That seems to make it very likely that the eventual mach_port_deallocate()
> in the kernel destroys the port.

I did compile CCL with in shutdown_thread_tcr () a call to
mach_port_destroy ().
(This conceptually of course very wrong.  I don't even know
what happens, is the thread immediately killed??)
But this worked for my trivial test case and stopped the mach port leak.

Your fix is of course better.
However the aesthetic in my wants to have the reference counts nicely
balanced.  So I maybe I spend some more time on it, but at the moment
I don't know where to start looking.


Thank you for looking at it.

Kind regards,
Wim Oudshoorn.