Enhanced tokens for more flexible memory management

[edwardalee]

In our conversation with @rcakella today, it became clear that we need to enhance the token mechanism in the C infrastructure with a token that carries its own destructor. Specifically, you can currently use some of the SET functions, for example SET_NEW, to dynamically allocate memory for an outgoing message, and then a reference counting mechanism is used to later free this memory when it is no longer used. But this will not work if your message is, for example, a struct that contains pointers to dynamically allocated memory. Only the struct will be freed, not the pointed to memory. A simple solution, I think, would be to augment the token_t struct with a destructor, a function pointer. If this is NULL, then free() will be used, as now. If it is non-null, then the specified function will be invoked instead. We will then provide another variant of SET that takes the destructor as an argument.

[housengw]

passing the destructor to SET_NEW might be tricky in the remote federated case since the token at the input port of the receiving federate is allocated using a network control reaction under the hood (in federate.c). This suggests that the destructor needs to be serialized and sent through the network, which is a bad idea from the security perspective and technically challenging for cross-platform programs.

I think a cleaner solution might be to make the destructor part of the data struct instead of the token struct. The compiler could throw an error if the data struct passed to the destructor variant of SET_NEW does not have that destructor field.

Edit: having the destructor in the data struct wouldn't work either since under the Native serialization the destructor would also get sent to the receiver federate

[edwardalee]

I had not thought about using the token destructor across federates. In fact, I don't think it makes sense to use across federates. I think we should rely on the serialization/deserialization scheme to be able to work at the receiving end with the default destructor (which just calls free()). The sending end could use the provided destructor after serializing the data.

[housengw]

closed by #66