Problems with ordering of chains of actions/effects

[arximboldi]

This is something that in the beginning I thought is a modeling problem, but I'm starting to find situations that make me wonder.

Example, we have action1, finish_action1, action2

• action1 returns an effect that does something (maybe something as innocent as reading a time-stamp) and dispatches finish_action1, eg:

[](auto&& ctx) { ctx.dispatch(finish_action1{}); }

• action2 does something, that can be dependent on state touched by finish_action1.
• The user does:

dispatch(action_1{});
dispatch(action_2{});

The execution we get is however action_1, action_2, finish_action1, even if maybe one could expect (or require for correctness): action_1, finish_action1, action_2.

One solution would be to ensure that the effects from an action an all actions dispatched within it gets queued before any other actions in the queue. The implementation seems not trivial and can add a small overhead also in cases where it may be not necessary, since it requires keeping a nested queue for actions dispatched within the effect.

Considertions are:

• Should we put this aspect of queueing in the event_loop interface?
• Should we add a method dispatch_nested() to consider this special scenario?

[altschuler]

I think it would be more confusing if the effects of action1 are waited for before scheduling new actions. If one required the sequence to be action1, finish_action1, action2, then action2 might as well be an effect of finish_action1. If that's not possible (for whatever use case reason), you could set some state and watch it to know when action1 finished doing it's thing.

In my mind the effects are not something the consumer should be dealing with (or necessarily even aware of), that makes it much harder to reason about what is going to happen.

I still think it's a modeling problem :) I haven't worked much with effects in lager yet, but that's my immediate opinion based on experiences from other state management libs.

[arximboldi]

I feel you. I think I would need to elaborate a bit the concrete examples that motivated me to open the issue. I'll keep thinking about this... I don't think I will change this soon.

[tusooa]

I feel this is somehow similar to #96 . I ended up using a Promise-like interface but the Promise had to be single typed or the interface cannot make use of virtual functions, which, again, is annoying.

[arximboldi]

What do you mean that the promise has to be single-typed? tusooa ***@***.***> writes:

…

I feel this is somehow similar to #96 . I ended up using a Promise-like interface but the Promise had to be single typed or the interface cannot make use of virtual functions, which, again, is annoying. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #106 (comment)

-- ∿∿∿ https://sinusoid.al ∿∿∿ https://sinusoid.es

[tusooa]

Ideally one should be able to do `promiseHandler.create<Type>();`. But in things like lager::store, we do not want to know what exact type is `promiseHandler` of. Thus we need to make use of explicit or implicit virtual functions (as in the event loop interface implementation), but template functions cannot be virtual, so we are limited to specifying Type beforehand. If you know of a way to bypass this limitation I would be happy to hear -)).

…

________________________________ From: Juanpe Bolívar ***@***.***> Sent: Monday, April 26, 2021 12:39:43 PM To: arximboldi/lager ***@***.***> Cc: tusooa ***@***.***>; Comment ***@***.***> Subject: Re: [arximboldi/lager] Problems with ordering of chains of actions/effects (#106) What do you mean that the promise has to be single-typed? tusooa ***@***.***> writes:

I feel this is somehow similar to #96 . I ended up using a Promise-like interface but the Promise had to be single typed or the interface cannot make use of virtual functions, which, again, is annoying. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #106 (comment)

-- ∿∿∿ https://sinusoid.al ∿∿∿ https://sinusoid.es — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#106 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AACJGYL5EA5EDIHE5OYHJTDTKWJM7ANCNFSM42Y644QQ>.

[arximboldi]

I use some tricks in context to be able to dispatch actions of multiple types. Maybe that would help.

[tusooa]

I use some tricks in context to be able to dispatch actions of multiple types. Maybe that would help.

But it is still the case that one should specify the range of types, which is what I am trying to avoid.