Charm++ parallel programming system

[Nicolas Bock <nicolasbock AT gmail.com>]

Thanks so much for the explanation. I wasn't aware of the subtleties involved in the different uses of pup(). But the ckDestroy() route sounds definitely more robust.

nick

On Mon, Aug 5, 2013 at 8:57 AM, Phil Miller <mille121 AT illinois.edu> wrote:

Actually, I think the flag you would want to use is PUP::isDeleting(),
since isPacking() may also being used in debugging or checkpointing,
in which the object may be packed but not migrated.

However, I believe a better design (if I correctly guess what you're
doing) would be to override ArrayElement::ckDestroy() in your chare
class to set a flag indicating that the impending destruction is not
due to migration, and then call the base class ckDestroy(). That is
unequivocally on a path that's only followed when the code has
explicitly asked to delete an element, and therefore not due to
migration.

On Wed, Jul 31, 2013 at 4:13 PM, Pritish Jetley <pjetley2 AT uiuc.edu> wrote:

> You could set a flag in the pup(PUP::er &p) call when p.isPacking() is true.
> This flag could then be examined in the destructor to tell whether the
> object in question has been packed (and presumably migrated).
>
> Pritish
>
>
> On Wed, Jul 31, 2013 at 1:11 PM, Nicolas Bock <nicolasbock AT gmail.com> wrote:
>>
>> Hi,
>>
>> is it possible to tell inside a destructor whether it was called because
>> of a migration?
>>
>> Thanks,
>>
>> nick
>>
>> _______________________________________________
>> charm mailing list
>> charm AT cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/charm
>>
>
>
>
> --
> Pritish Jetley
> Doctoral Candidate, Computer Science
> University of Illinois at Urbana-Champaign
>
> _______________________________________________
> charm mailing list
> charm AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/charm
>

> _______________________________________________
> ppl mailing list
> ppl AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/ppl
>