Actually, only fork() and exec() invalidate the Mach ports. The current

vfork() implementation actually arranges for the Mach task associated

with the parent to be shared with the child (resulting in two procs

running in one Mach task and having equal access to Mach resources like

ports and VM). But it's only an implementation artifact and you

shouldn't depend upon it. You must stick to the list of vfork()-safe

APIs and behaviors (exec(), _exit(), not popping the stack, etc...) to

assure continued operations regardless of the implementation.

I just tried that with my library and all of my IOUSBDeviceInterfaces work with both the child and parent. I will have to keep that in mind. Its too bad I can't rely on that because it is exactly what i need (and expected from fork).

There is no [guaranteed safe] way to re-validate them under the same

port name with the same number of references (thus making the port

names sprinkled throughout the process memory valid again). But there

are some common techniques used to pass send rights to these ports from

the parent to the child under a [randomly chosen] new name. And many

of the frameworks allow for instantiation of objects passing an

explicit port to use - rather than looking them anew. I'm not sure

about IOService, however. You can't just open a new IOKit service

connection in the child? This is sometimes impossible because the

parent was privileged and the child not (so I feel your pain).

I have tried to open a new connection to iokit with the child process by calling IOCreateMasterPort again but I get the same result as when I didn't. The problem must lie in the IOService which looks like it keeps trak of the master port used to open it. It would be a really simple fix if i could rely on the programmer to call usb_open on a device after the fork call (i think. i know there are a number of ports invalidated that I don't really know about). Thanks for your reply. I am just starting to get a handle on the mach/bsd kernel used in darwin and how it differs from a traditional bsd kernel. -Nathan _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.