Document Serializable STL containers

[Dan Bonachea]

John said:

When writing the non-boost serialization, I taught it how to serialize some of the std containers. I didn't advertise it out of conservatism. But its there and very unlikely to disappear. [...] std containers supported by the implementation at the moment are: vector, unordered_set, unordered_map, string, pair, tuple, array.

This list of STL types that our implementation considers automatically Serializable needs to be documented to be useful to users. This doesn't seem like it belongs in the spec, since it's more a feature of the implementation (and might conceivably eventually depend on details of the libstdc++ in use).

Perhaps in README or a new document in docs that lists implementation-specific behaviors?

[Dan Bonachea]

John reports these STL types are currently only Serializable when used with RPC, and not RMA (which requires a protocol change to achieve remote (de)serialization)

[BrianS]

What is the issue with rput/rget and std container serialization? I think what this means is that we have nothing automatic for when a user calls

std::vector<double>  values({23, 45, 16, 12});
auto f = rput(remoteRank, values);

but we would handle the case like

std::vector<double>  values({23, 45, 16, 12});
auto f = rpc(remoteRank, [values]() { std::reverse(values);  return values;});

in the above example send the vector values to remoteRank. It reverse the entries and returns the value to my future.

[Dan Bonachea]

In the 1/10/18 meeting, we tentatively resolved to remove the Serialization feature from RMA operations, which will always assume the type is POD and safe to perform byte-copy RDMA. See spec issue 112

So this remains just a documentation issue for STL types passed to RPC. Do we document a list of STL types as serializable? Alternatively we can instead encourage users to use serialized_view on these containers to move the raw data, and leave it to the RPC callback to instantiate a new container at the target (with a required payload copy) if the app really needs that?

[john bachan]

The current list of supported STL containers: tuple, pair, array, vector<T>, unordered_set<T>, unordered_map<K,V>. Note: vector unset and unmap only work with the default values for their implementation parameters (such as the allocator or hash function or equality function).

[Dan Bonachea]

This issue was triaged at the 2018-06-13 Pagoda meeting and assigned a new milestone/priority.

We noted the upcoming programmer guide will likely exploit STL container serializability, so we really need to officially document this feature (exact doc location TBD).

[Dan Bonachea]

Added to docs/implementation-defined.md in 9554e6f