Re: MoreSCF and masterPort
Re: MoreSCF and masterPort
- Subject: Re: MoreSCF and masterPort
- From: Quinn <email@hidden>
- Date: Thu, 7 Nov 2002 12:04:40 +0000
At 10:17 +0100 7/11/02, Jirome Foucher wrote:
I've noticed that MoreSCF often gets the masterPort using IOMasterPort
But I came across a sample code that disposes of the masterPort
after using it by calling mac_port_deallocate. This is something
MoreSCF doesn't do.
I'm not an expert with the IOKit so I'm quite unsure if it's normal
or if there's an issue here...
Could someone clarify this ?
The master port is reference counted, so getting it repeatedly is not
going to cause a memory leak. Also, the master port is cleaned up
when you quit the application, so for normal application code there's
no reason to mach_port_deallocate it.
However, there are two cases of interest here.
1. MoreSCF should cache the master port rather than repeatedly
getting it. The current behaviour could eventually wrap the
reference count for the master port, which is probably bad.
It so happens that I have MoreSCF open at the moment (for another
project) so I've changed the code as shown below.
static mach_port_t gMasterPort = 0;
extern pascal OSStatus MoreSCCreatePortArray(CFArrayRef *portArray)
// See comment in header.
{
kern_return_t err;
CFMutableArrayRef result;
CFStringRef keys[2];
CFStringRef values[2];
MoreAssertQ( portArray != nil);
MoreAssertQ(*portArray == nil);
result = nil;
err = CFQArrayCreateMutable(&result);
if (err == 0 && gMasterPort == 0) {
err = IOMasterPort(bootstrap_port, &gMasterPort);
}
[...]
}
2. If you put MoreSCF into a loadable shared library (such as a
network setup CFBundle that you load into your CFM application), you
probably should mach_port_deallocate the master port before you
unload the shared library (and hence destroy the gMasterPort static
variable). I haven't made this change in MoreSCF because I'm still
thinking about this issue for MoreIsBetter as a whole (for example,
other parts of MIB leak UPPs in this case, and if I fix the master
port 'leaks', I should also fix the UPP 'leaks', which is more
tricky).
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.