One thing I do not see mentioned, and feel could use some attention, is thread safety. (aka other threads altering the graph you are serializing)
> The classic answer would of course be "always run FUEL at highest > priority", but if we ever want to move to true multi-core, that's not > enough. > > Wow. Were you reading our minds?? hehehe. Yes, reading some of the related work papers while writing our own paper, we read about the "atomicy". How to be atomic while analyzing and serializing? Right now, if the graph changes between the first phase (analysis) and the second phase (serializating) you are screw :) I wonder if Eliot fixed that in Parcels? What would be neat is protecting all mutation of objects in the graph with a > Mutex/Monitor whose critical section covers the analysis and serialization, > i.e. blocking all other processes that wants to mutate objects in the graph > untill serialization is complete. > > yes, > Aside from the behaviour when a marked object is encountered, the process > is the same as for immutability, as discussed here: > http://forum.world.st/**immutability-and-become-Was-** > Re-squeak-dev-immutability-**td1597511.html<http://forum.world.st/immutability-and-become-Was-Re-squeak-dev-immutability-td1597511.html> > > You could do this image-side as part of the analyze phase, as Eliot's post > suggests, Ok, but in order to do I need the immutable bit in the ObjectHeader, right? > but it's not entirely safe when: > A child -> B > B parent -> A > > 1 . Process1 protects A with Mutex > 2. Process2 calls method on B which does: > a) B parent: C > b) (B's tmpRef to A) child: somethingElse *Wait for Mutex* > 3. Process 1 makes B, C immutable, serializes B with C as parent. > 4. Process2 changes A child. > > It could of course be argued that is a programming/logic error to update B > parent ref before child ref in A, (you'd actually have to do extra work to > get that order), still it's a hard one to debug if it does happen. > (Note to the thread: Following the same logic, I would also say it should > be considered an error to keep a mutable cache as part of an immutable > object :) ) > > In fact, you *could* implement it with immutability, injecting handler > contexts with behaviour as described above into existing/new processes for > any resulting immutability errors. > > wow. Seems a really complicated stuff to deal with :( Immutability is not yet present in default VMs -- Mariano http://marianopeck.wordpress.com
