<heller>
hkaiser: should we rather go with tag types for the extra data than with indices?
<heller>
hkaiser: pointer tracking is also kind of a core feature of the archive, I think. any particular reason you put that as part of the extra data stuff?
hkaiser has quit [Ping timeout: 276 seconds]
<heller>
disregard my second statement...
weilewei has joined #ste||ar
<diehlpk_work>
jbjnr_, Which branch should I use to compile HPX with libfabric?
<diehlpk_work>
Are there any special things, I have to do for power9?
aserio1 has joined #ste||ar
hkaiser has joined #ste||ar
aserio has quit [Ping timeout: 240 seconds]
aserio1 is now known as aserio
<hkaiser>
heller: see #4114
nikunj has quit [Quit: Bye]
<heller>
hkaiser: did you run the performance test yet?
aserio has quit [Ping timeout: 245 seconds]
weilewei has quit [Remote host closed the connection]
aserio has joined #ste||ar
weilewei has joined #ste||ar
<hkaiser>
heller: I have not
<heller>
ok
<heller>
hkaiser: Why did you go for index based lookup instead of type tag?
<heller>
hkaiser: index based might not be a good option for being externally extensible
<hkaiser>
heller: because the archive does not know anything about the types
<heller>
sure, only the user of the the extension
<heller>
but what if I add an extension with index 1?
<hkaiser>
heller: lthen you're screwed
<heller>
right
<hkaiser>
it will throw
<heller>
that's what I am saying, can't I do an any_cast<T> instead?
<heller>
or something like that?
<hkaiser>
the archive holds an array of types
<heller>
yes
<hkaiser>
so which one of its elements you want to do the any_cast with
<heller>
the right one :P
<hkaiser>
hah!
<heller>
I was thinking along the lines of extension info though
<hkaiser>
well, I didn't know how to solve this efficiently
<heller>
where you could do a static_cast to the right super class and get the righ thing (tm)
<hkaiser>
I think the current solution is fine as you will not change the data stored in the archive too often
<hkaiser>
in which case it requires a bit of corrdination
<heller>
yes, potentially making two different libraries incompatible because both choose the natural index 2 for their data
<heller>
since 0 and 1 are already taken
<heller>
or make it 3 ...
<heller>
and we can't easily add more
<hkaiser>
heller: no
<heller>
no?
<hkaiser>
your library will use your data
<hkaiser>
so you know what you're serializing
<hkaiser>
if you wan to also support HPX types you will need to ad your archive extension types to the end
<heller>
yes, but in order to extend the archive, like what you have done for 1) size calculation 2) future awaiting and 3) gid splitting
<hkaiser>
1) is pointer tracking, not size calculation
<hkaiser>
heller: well, if you have an idea how to do this, pls let me know
<K-ballo>
hkaiser: do you still use ramdisk?
aserio has quit [Ping timeout: 264 seconds]
<hkaiser>
K-ballo: yah
<K-ballo>
I'm limited to 3gb, which is proving insufficient
<K-ballo>
presumably the new paid version can go above it
<heller>
to allow the serialization archive to be extended from the outside, to for example handle hpx::future or hpx::id_type correctly without the archive needing to depend on either of them
<heller>
to be able to say something like ar.get<future_handler>()->attach_future(f);
<heller>
or ar.get<split_id_handler>->add_split_gid(gid);
<heller>
inside the serialization functions of future, or id_type that is
<heller>
(with appropriate checks if those have been indeed been added to the archive at construction
<heller>
so get might return nullptr
<K-ballo>
I assume you've considered how shared_ptr is integrated with boost.serialization already
<heller>
no
<K-ballo>
boost.serialization has some sort of extension mechanism, which allows external types to customize serialization, in particular shared_ptr wants to preserve references
<K-ballo>
I've only heard of it, I've never actually seen it in code
<heller>
ok
<heller>
I looked at the pointer tracking once
<heller>
which is similar
<heller>
and we have that as well
<heller>
hkaiser wants to have that as part of the mechanism as well
<heller>
last time I looked at it (before we wrote our own serialization) there was no such extension mechanism