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

[Willem Rein Oudshoorn]

Gary Byers <gb at clozure.com> writes:

> On Wed, 23 Feb 2011, Wim Oudshoorn wrote:
>
>>> 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.
>
> It (or at least a major source of it) doesn't come from CCL.
>
>
> The message(s) sent to the various exception ports include the kernel
> thread object (the port); naturally, the kernel conflates the ideas of
> "referencing that object" with the idea of "retaining that object" in
> this context just as it does in other contexts. It never releases that
> reference (presumably since doing so would make at least some sense.)

Ah, this makes perfect sense.  I have been reading up on the mach
architecture and it slowly starts to click.

The receiver gets a message describing the exception.
In the message some port rights are send.  The receiver receives
these rights and the rights are now his to do with what he pleases.
One consequence is that if the receiver does not deallocate these
rights, they will linger on.  

[I read a text somewhere in the mach documentation but it did not click
before.  The text stated something like that if you received a right,
you have to deallocate it.]

I can see that rationale:

1 - Not all messages need a return message, so the sender
    can not dealloc the rights

2 - The sender can live in a different namespace, so 
    when the message is transported a new right (name) is created
    in the receivers namespace.  This right belongs in the receiver
    namespace and as such the sender can not touch it.

2a - You could argue that the kernel, who does the transformation
     in step 2 should deallocate the rights.  But the kernel
     still has problem 1. 

3 - To make it consistent, have the policy that all rights
    that are send to a receiver are the responsibility of the receiver.


Note: the mach_... calls are thin autogenerated wrappers on the
      actual mach msg send functionality. These wrappers are quite
      thin and do not alter the semantics of the content of the messages.


> I checked this in to the trunk about 10 hours ago.  It seems to fix
> the port leakage and I haven't seen evidence of any new problems
> having been introduced, but this stuff is complicated enough that it's
> hard to say that for sure.


I have an alternative fix, which does all the deallocates in the
appropriate places.  It works for me and all reference counts are 
in my case low and do not increase.  Also no more dead ports lingering
around.

I can make this into a patch for you if you tell me what you would need.
I assume that it should be based upon the most recent development
version.  But in what format would you prefer it and where do I send it.
I will need some time to get it complete.  That is, the powerpcc
version need to be made etc.   
Let me know if you are interested, otherwise I will not waste time
on it anymore.

Kind regards,
Wim Oudshoorn.