Technical limits on event payload types

[Daniel Austin]

This is a continuation of a topic I started on the chat room, moved at fsantanna's suggestion.

My original question:

Hi, all. I am curious what the limits on event payload are, in a technical sense. Right now the 0.30 syntax only allows Types. Could I, in theory, send code locations that are received and then spawned at the reception site? Could I send an event reference as an event payload? Event references already work fine as code input parameters, so I don't see why not in that case. Thanks.

fsantanna's reply:

Pointers and references as payloads are tricky.
Consider this case:

par/or do
    par/or do
        var int a = ...;
        emit e(&a);
    with
       await e;
    end
with
    ref = await e;  // dangling ref (a is out of scope)
    ...
end

(BTW, I think this kind of stuff should be sent to the mailing list.)

Continuing....

I understand that use case would be dangerous and should be illegal.  In some sense, dereferencing a reference is a "pull" operation, and it's possible that when you "pull" on on the reference, the referenced variable could go out of scope.  That makes sense.

For events, though, awaiting on an event I see as a "push" operation.  Say it were possible to await on an event carrying an event reference as payload.  E.G,

event int int_event;

event (event& int) ref_sender;

emit ref_sender(&int_event);

<in some other trail...>

event& int my_ref = await ref_sender;

After my_ref is received, I believe the only possible operations are to either emit on it or await on it.  If the reference to int_event is still valid, both operations are fine.  If the reference to int_event is dangling, then

await case: because int_event went out of scope, no other trail can emit on it, so an await on my_ref would wait forever for an event that could never come.  (Or perhaps if the int_event came back into scope somehow, the reference could become valid again.  It depends on how the runtime implements event locations and trail memory, I think.)  The await forever case doesn't seem like a significant issue because that's possible any time await is called without par/or timeout logic.

emit case: trying to emit on my_ref would be a big problem if the reference is dangling.  This is analogous to dereferencing a dangling var reference.  There could be other important stuff at that memory location now.  This operation would need to be prohibited.

To resolve those, there could be a new type called event...listener? that works just like an event reference with the following two modifications: it can be used as an event payload and it cannot be emitted on.  I *think* it would just be a syntax change to prevent the runtime from doing something dangerous with a dangling event.

===

Code as event payload could provide some interesting use cases if it's technically feasible.  Would it have the same dangling issue as var and event references?  Functions in C never go out of scope; you either see them and can use them or you can't.  Code abstractions in Ceu aren't really the same as functions, though.  I think the feasibility of this depends on how the runtime allocates memory for spawn and await calls on code abstractions.  Two code abstractions could have the same "function signature" but require different memory layout depending on what they do.  A trail that receives a "code" as event payload and wants to spawn it or await on it might not know how to.

Thanks for reading,

Dan

[Francisco Sant'anna]

On Sun, Feb 10, 2019 at 1:41 AM Daniel Austin <daniel....@gmail.com> wrote:

await case: because int_event went out of scope, no other trail can emit on it, so an await on my_ref would wait forever for an event that could never come.  (Or perhaps if the int_event came back into scope somehow, the reference could become valid again.  It depends on how the runtime implements event locations and trail memory, I think.)  The await forever case doesn't seem like a significant issue because that's possible any time await is called without par/or timeout logic.

The runtime does not track scope, it just assumes the type system will prevent out-of-scope accesses.

Tracking would be very costly and confusing.

The exception is with the `&?` modifier for references.

However, currently you cannot use them in event payloads. That might change in the future (allowing events and code as well).