search

humdek-unibe-ch / smx-core-rts

The runtime system (RTS) library for the coordination language Streamix.
Mozilla Public License 2.0
0 stars 0 forks source link

Message States #5

Closed moiri closed 5 years ago

moiri commented 5 years ago

In order to communicate deadline misses (or other events) to box implementations the message structure should include a state field.

This field can then be used by the box implementation to take appropriate action.

This means that the SMX_CHANNEL_READ macro should only return NULL on an unexpected error.

moiri commented 5 years ago

Further add a struct timespec field to the message structure which is filled with a timestamp upon message creation (use clock_gettime(CLOCK_REALTIME)).

moiri commented 5 years ago
moiri commented 5 years ago

I am not sure that a message state is the best way to approach this item. I guess that the initial idea was to inform the box implementation about a DL miss in order for it to take appropriate actions. Some thoughts about all of this:

Currently, a TF can be configured in two ways on a DL miss of the producer:

  1. the last message is duplicated and returned by the read function
  2. the read function returns NULL

In case 1, I don't see any reason why the box should be informed about the DL miss. After all, the experimenter decided it would be perfectly fine to provide a duplicate of the last message for the consumer to continue its computation. If the consumer must take actions on a DL miss of the producer, certainly a TF would be configured to correspond to case 2.

Concerning case 2, the relevant question is: must a box know whether a DL was missed or is it sufficient for it to know that no message was produced where it should have been?

I can think of two scenarios where such a distinction is necessary:

  1. Differentiating between a graceful termination and a DL miss or a failure of the producer.
  2. Executing a box periodically if possible (to reduce jitter), not duplicating messages but also ignoring DL misses (i.e. a read returning NULL is acceptable).

Conclusion: Yes, DL misses should be reported to to the consumer box, however, in order to keep the read function as simple as possible I would try to avoid a message state but provide a function that allows to query the channel state. In the case of the read function returning NULL the channel state could then be queried in order to take appropriate actions.