co::Serializable / (get)applyInstanceData / (unpack)pack question

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: co::Serializable / (get)applyInstanceData / (unpack)pack question

Stefan Eilemann
Hi Petros,

On 11. Nov 2014, at 9:10, Petros.Kataras [via Software] <[hidden email]> 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) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: co::Serializable / (get)applyInstanceData / (unpack)pack question

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 <[hidden email]>
 wrote:

> Hi Petros,
>
> On 11. Nov 2014, at 9:10, Petros.Kataras [via Software] <[hidden email]> 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
> Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.
>
> _______________________________________________
> eq-dev mailing list
> [hidden email]
> http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
> http://www.equalizergraphics.com


_______________________________________________
eq-dev mailing list
[hidden email]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
Loading...