> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons > > Leo Sutic wrote: > >>From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons > >> > >>again, from memory, the real tough part is the barrier that's > >>in place around the reference. > > > > I'd say the hard part is when A has significant state that isn't > > preserved when it dies. > > right! Any reason it can't be preserved?
In theory no, in practice it isn't cost-effective to implement all that code. Therefore it won't be done. > reminds me of Persistable... > > > 1) A active > > 2) schedule swap of A with B > > 3) prepare swap to max extend (ie create and initialize B) > > 4) suspend A and all processes referencing A > > 5) swap > > 1) stop A > 1.5) save A state > > 2) kill A (if it doesn't respond) > 2.5) load A state into B > > 3) start B > > 4) update reference > > 6) resume A and all processes referencing A > > the problem is that step 5 just keeps getting more and more > expensive...and for all intents and purposes, needs to be atomic. The idea I'm looking at is when A and B interact via short sessions - for example, the time between a lookup and a release. As long as B is released by A when you swap, you can just kill it. Avalon semantics do not require B to maintain state across lookups. So you do the barrier thing: block or fail lookups until all B's have been released, the swap. /LS
