Peter Memishian wrote: > > 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. >
Pure speculation on my part, I don't know how they implemented their allocation functions. > > 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. > If we call door_create before daemonizing, the door is available for anyone to use. Someone could use svcadm to restart linkmgmtd, and then do an ifconfig plumb. If they timed it correctly, and we changed linkmgmtd to do door_create before daemonizing, then it is possible that door upcall from the kernel as a result of the ifconfig plumb could come in before we daemonize. > 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. > Ahh, right, I forgot about that. Scratch my original idea, it won't work then. Dan
