Token types

[cmnrd]

After yesterdays meeting, I kept thinking a bit about token types in C and would like to share
some of my thoughts.

I think smart pointers provide two key features:

1. Automatic memory management
2. Explicit modeling of ownership and move semantics

Apparently 1. has not been implemented correctly so far and the solution that Edward works on at the moment seems to be rather minimalistic and not a general implementation of smart pointer semantics.

For 2, to be useful, the user needs to be provided with an API for manipulating the smart pointers. E.g., there should be API functions for creating new pointers of a certain type, for moving ownership from one pointer two another, for copying pointers (not the data), and for invalidating a pointer. It seems like such API functions do not exist (at least they are not documented). Only with such functions available, one can freely create new smart pointers, store them in some local variable or a state variable, move them into a port, and move them back out again into a state variable on the receiving end, all without copying.

So if the C target does not use 2., and 1. is only implemented in a minimal version (i.e. the smart pointer is invalidated when
overwritten), then I am wondering: Why do we even need dynamic memory allocation and reference counting pointers?

I think it would be much cleaner to just store an instance of the data type (be it an array or a struct) directly within the sending port. All receiving ports could simply receive a pointer to this data instance and the data itself would be persistent (i.e. it is valid until overwritten at a later tag). If the user needs to keep the value for a longer time, they should copy it manually (I believe this is also the case now as there seems to be no way to copy a smart pointer (not the data) and increment the reference counter explicitly).

Generally, I think that smart pointer semantics are very useful and I would advocate to fully support them in the C target. The C++ target proofs that this can be done efficiently without much overhead. If, however, this seems to much work or there are other reasons speaking against full smart pointer support, I would argue that we should not support them at all.

[edwardalee]

@cmnrd writes:

I think it would be much cleaner to just store an instance of the data type (be it an array or a struct) directly within the sending port. All receiving ports could simply receive a pointer to this data instance and the data itself would be persistent (i.e. it is valid until overwritten at a later tag). If the user needs to keep the value for a longer time, they should copy it manually (I believe this is also the case now as there seems to be no way to copy a smart pointer (not the data) and increment the reference counter explicitly).

This is exactly what we are doing. The current implementation unnecessarily includes in the reference count the number of receiving ports, however, and goes through a song-and-dance at time advance of decrementing these reference counts. These hit zero, and the memory is freed, therefore violating persistence and leaving receiving ports with a pointer into freed memory.

In my branch, the output port is a single referrer, incrementing the reference count by just one. A receiving port can take the data and pass it to lf_schedule_token, which puts it on the event queue an increments its reference count to 2. When the output port data gets overwritten, the old token's reference count is decremented to 1, not 0, so the memory is not freed (it is referred to by an event on the event queue). When that data is pulled off the event queue (decrementing the reference count) and put into an action (incrementing the reference count), it will still have a reference count of 1, so it will also persist in the action until overwritten.