Peter Memishian wrote: > > 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.
This is true. During boot, the idea is to delay daemonizing until the door is ready (i.e., after door_create()), so that dependent services don't attempt to indirectly access the door until after the server is ready to receive calls. I believe, however, that what Dan's describing is a scenario whereby the daemon is being started and some process attempts to use the door in the window between door_create() and daemonization. Maybe this isn't during boot and someone typed "ifconfig plumb bge0" while the daemon was being restarted, and the daemon is in the process of servicing an upcall while daemonizing. Will this cause a problem? Do we care? > 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. Yes, but the event Dan's concerned about isn't the door file creation, but the creation of the server procedure within the daemon (door_create()). -Seb
