site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 10/20/08 8:17 PM, Terry Lambert said: However, it would be better if you didn't depend on there being a safety net there, and only pass in valid object references for which you've previously done a retain. Terry, if (device->X) { IOObjectRelease(device->X); device->X = 0; } -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Oct 21, 2008, at 7:56 AM, Sean McBride wrote: 1) How does IOObjectRelease() react to being given null? Does it do nothing like free() or crash like CFRelease()? Yes, I could try, but I'm looking for an API guarantee one way or the other. 2) Is IOObjectRelease() threadsafe? Specifically, if I create some object on the main thread, is it safe to IOObjectRelease() it from an Objective-C garbage collector finalize method (which runs on its own thread)? If you pass it a NULL, that is the same as MACH_PORT_NULL, which makes MACH_PORT_VALID() false, which makes mach_port_deallocate() simply return KERN_SUCCESS, which causes the function to return that. Thanks for this info. Any idea about calling IOObjectRelease() from finalize? I'm not really an IOKit expert, it's just that your question was hanging out there for a while. 8-). We appear to do it in a bunch of places in code we've published, although in the ones I looked at, most of them protected against calling with NULL, e.g.: ...not to happy with the use of 0 instead of MACH_PORT_NULL, but that intentionally plays loose tying games anyway, so it's just 0, so I can't complain too much. I think the reason it does this is because it's possible to tear down the devices from either user space or from kernel space, based on having received a hot-plug event. If these race, then you want to make sure that you've marked the device invalid, so it looks like they use the 0 for that. I also see it happen in the delete routine or in the connection notification event, rather than in the finalize in a number of places, which might avoid the issue of needing to check for the 0 as a marker by delaying things until later, at the cost of holding resources for a bit longer. This email sent to site_archiver@lists.apple.com