cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [Kernel22] How to develop a component?
Date Fri, 09 Apr 2004 11:10:51 GMT


> From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
> 
> Leo Sutic wrote:
> >>From: news [mailto:news@sea.gmane.org] 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


Mime
View raw message