Sebastien Roy wrote: > Dan Groves wrote: >> I agree it's something else, but I think we still have a race >> condition here. >> >> linkmgmtd does all of its SMF and door call initialization after it >> daemonizes. When linkmgmtd daemonizes, it returns and the SMF start >> script for the linkmgmt service continues. SMF could then start nwamd >> before linkmgmtd has finished its initialization. > ... >> We'll need some mechanism to make sure linkmgmtd is finished its >> initialization before SMF tries to start other things. I wonder if we >> could use the door file for this? Initializing the door is the last >> thing linkmgmtd does when it initializes. Say have the start up >> script delete the door file, then linkmgmtd will recreate the door >> file when it initializes the door, and once the door file exists, the >> start script can terminate. We can have the start script give up >> after a while if the door file never shows up (to keep from hanging on >> boot). >> >> thoughts? > > Why not modify linkmgmtd to not daemonize until it has completed its > initialization, including door setup? > > -Seb
Because it is too obvious a solution ;) On a serious note, there are some problems. 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. 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. Maybe this idea could work (I think it would be great if it could), but I think it would be a little more complicated than changing when we call fork (or forkall). thanks, Dan
