[eq-dev] co::Serializable / (get)applyInstanceData / (unpack)pack question

[Petros.Kataras]

Hi,

just wanted to clarify some concepts regarding the (de)serialization
mechanism when using co::Serializable.

The documentation reads:

"For serialization, the default co::Object serialization functions are
implemented by co::Serializable, which (de-)serializes and resets the dirty
bits, and calls serialize or deserialize with the bit mask specifying which
data has to be transmitted or received. During a commit or sync, the current
dirty bits are given, whereas during object mapping all dirty bits are
passed to the serialization methods."

What I understand from this is that (get)applyInstanceData is used only
during object mapping with passing DIRTY_ALL to (de)serialization and from
then on (unpack)pack is used only with the current dirtyBits that are passed
to the (de)serialization functions.

What I notice though if I run eqPly is that the (de)serialization functions
are called for both DIRTY_ALL and with the actual dirtyBits set at each
commit/sync.

Am I missing something here and if not could I get some more info about the
rationale behind this??

Thanks!

Petros



--
View this message in context: http://software.1713.n2.nabble.com/co-Serializable-get-applyInstanceData-unpack-pack-question-tp7586656.html
Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.

_______________________________________________
eq-dev mailing list
eq-...@equalizergraphics.com
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com

[Stefan Eilemann]

Hi Petros,

On 11. Nov 2014, at 9:10, Petros.Kataras [via Software] <ml-node+s171...@n2.nabble.com> wrote:

> What I notice though if I run eqPly is that the (de)serialization functions are called for both DIRTY_ALL and with the actual dirtyBits set at each commit/sync.
>
> Am I missing something here and if not could I get some more info about the rationale behind this??

The documentation is trying to convey the concept, but the implementation differs in some places. The documentation is correct for unbuffered objects, but for buffered (instance/delta) the object has to retain a full copy of each version to allow late mapping (or how would the new slave instance get an old snapshot of the master?). The mapped instances only get the delta since the last version.

The documentation in master looks different already:

/**
* Worker for pack() and getInstanceData().
*
* Override this and deserialize() to distribute subclassed data.
*
* This method is called with DIRTY_ALL from getInstanceData() and with
* the actual dirty bits from pack(), which also resets the dirty state
* afterwards. The dirty bits are transmitted beforehand, and do not
* need to be transmitted by the overriding method.
* @version 1.0
*/

Or did I just not find what you quoted?


Cheers,

Stefan.
--
http://www.eyescale.ch
https://github.com/Eyescale/
http://www.linkedin.com/in/eilemann






signature.asc (858 bytes) <http://software.1713.n2.nabble.com/attachment/7586657/0/signature.asc>




--
View this message in context: http://software.1713.n2.nabble.com/co-Serializable-get-applyInstanceData-unpack-pack-question-tp7586656p7586657.html

[Petros Kataras]

Hi Stefan,

and once again thanks for such a fast reply!

Ok it makes sense now together with the change type detail.

The quote comes from the programming and user guide v1.14 for Eq1.6 in the section regarding co::Serializable (8.4.3).

In my case I am actually not interested for mapping older versions so I guess unbuffered would be the way to go except if I m missing some caveats that I am not aware about..

Thanks for the info once again!

Petros

P.S I ll probably will get back to you soon since I have to implement a generative particle system and I would definitely need some advice regarding possible optimizations / design suggestions on the distribution/handling of the data.. :)

On Nov 11, 2014, at 9:17 AM, Stefan Eilemann <eile...@gmail.com>
wrote: