Clarify serialization description

[Former user]

Instead of sentences like "serializing the items if T implements the UPC++ or Boost serialization interface", I think its better to say that T is serialized if necessary. This is incomplete without a defintion of what makes serialization "necessary". But once that it exists it will be more correct than saying whether a particular interface is implemented.

[Amir Kamil]

I'd prefer a different wording, as that implies that we make sure to serialize if it's semantically necessary, while we only do so if the type implements the serialization interface.

[Dan Bonachea]

On a closely-related topic:

Initiates a transfer of count items of type T from the local memory at src to the local or remote memory referenced by dest,

Wouldn't it be more concise and less distracting to just say "the shared memory referenced by dest" or even just "the memory referenced by dest"?

[Former user]

Semantically, serialization is always necessary since I consider that the process of transcribing values onto the wire. It just so happens that for some types the amount of CPU work and extra memory required before the value is in a form the NIC will accept (contiguous bytes in registered memory) is zero. So what we want to communicate is that resource consumption for serialization may or may not be necessary, but if it needs to happen it happens here. The best way to state this is just to say T is serialized (it just so happens that for some T's that costs zero energy). The drawback is that uninformed users may assume serialize=copy which isn't always the case. I think that's fine, we'll just state in the serialization section that types can be marked as trivailly_serializable.

Dan, shared memory does sound better.

[Dan Bonachea]

From the current spec for contiguous rput:

... Serialization will occur at an unspecified time.

Completion of this operation indicates that all source values have been serialized and the remote writes are complete.

These two statements are in direct conflict.

I thought we'd agreed that serialization for contiguous rputs would be guaranteed before the initiation function returns? Otherwise we need a local completion indication. I think the fix is to delete the first sentence above.

[Former user]

I think the direct conflict is acceptable. One sentence tells the reader that there is no specific time at which they can be sure serialization happened. The second sentence bounds that time to being before completion. I'm assuming they're clever enough to discover the other lower-bound on serialization time is operation initiation.

For rpc_ff, serialization must happen during initiation since there is no other notification. That's all I meant to agree to (perhaps I agreed to more at the time, now I've changed my mind). I definitely want rput to have deferred serialization so the implementation can pipeline it. I need to change rpc (non-ff) to also defer serialization since there is a notification.

This is all just for show, when the new API supports local-completion the user will be able to demand that local-completion is blocked for in initiation.