> We'll have two copies of all the data structures in memory. The parent > will need to clean up. If was just memory allocated with > malloc/calloc/etc., I wouldn't worry about it, it should be returned to > the system when the parent exists. But I'm not sure if SMF has > reference counts, I haven't look at their implementation.
You lost me on this one. SMF better be robust in the face of a process terminating prematurely -- if not, I'd think that would be a serious bug. > There's also the door threads. We could use forkall instead of fork to > solve this, and then have the parent revoke the door so that its door > threads don't handle any door calls. But what would happen if the > parent received a door call between when it initialized the door and the > parent calls forkall, and forkall is called before the door thread calls > door_return? I'm not sure if that scenario is possible, but if it is we > would have to handle it. I'm a little confused here. I thought the point of daemonizing later was to prevent other processes from attempting to make use of the door before it was ready. So why would there be attempted door calls prior to daemonizing? Seems like a chicken-and-egg thing here. As I recall, the door file is actually packaged (rather than being created on demand) so that we avoid having to create it early at boot when the filesystem is read-only. -- meem
