API Workshop #6 (Rust) [2025-05-20] #1110
darkwisebear
started this conversation in
Communication FT
Replies: 1 comment
-
Code from today's session: eclipse-score/inc_mw_com#7 (includes code from the previous sessions). |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Participants
@darkwisebear
@MarkSchmitt
Agenda
Minutes
On 1.
On 2.
Decision: We instantiate using generated code. Rationale: Putting the duty of instantiation to the generic code leads to all sorts of trouble (e.g. cyclic dependency between generic and generated code, need for HKT(?)). For the agreed package structure see the puml inside the source (link to come).
On 3.
subscribe
call? For SOME/IP this might be required since otherwise we'd need to subscribe to ALL events OR lazily subscribe in casereceive*
is called.Subscriber
contains three ways to receive: polling, async and blocking. Keeping it like this makes the implementation for Lola cumbersome and/or inefficient: Since each of these three ways requires a different callback setup (notifying, using a Rust Waker, or no callback) we would need to dynamically switch between these methods, switching the callback handler when the user uses different ways.This could be solved by providing a default implementation for the blocking calls that block on the future returned by
receive
. Other implementations could still override this by overriding the default implementation.Another option is splitting the trait into a sync and an async part or a blocking, async and polling part. In this case, each "mode" could be perfectly tailored towards its specific needs.
Beta Was this translation helpful? Give feedback.
All reactions