Claify and fix the initialization procedure

[lavrovvalera]

What

Based on the comment #18 (comment)

we need to clarify, agree and fix the initilizatio nprocedure and APIs

The full discussion is placed to the comments

How

No response

Estimates for realization

1 week

Category

• Affects Detailed Design

Requirements / Architecture

• Requirements / Architecture are not affected by this change?

[lavrovvalera]

The discussion:

Valery Lavrov  [1:43 PM]
Bjorn, regarding the Init

I would still propose to keep it. here are the arguments.

when the asil app will use it, we need to guarantee ther ewill be no memeory allocated durint the "Run", so we need the explicit "Init" time. We could treat the object creation as it, but I would beleive the explicit oen is better
without Init, the user shall always check IsAvailable or something to understand, he could use it. with Init it will be already clean on it. can we proceed or not
I'm a bit not convienced to fire additioanl thread on it during startup, would rather propose to shift that responsibility to the App itself

What do you think?
or if you concern is in general about the API
Init(), IsAvaialbe nad WaitUntilAvailable, I agree.
if Init is a blocking operation, it already returns the value. If the init will be done in background, then we need a polling API

I have then the proposal:

bool TryInit -> we are tring to initialize. blocking, returns bool. could be re-fired.
bool Init() or
bool WaitForInitialzation() which takes the stop token and threshold time -> it will call tryInit in a loop until time is reached or token is set or successfully Inited

IsAvailabel and waitUntilAvailable will be dropped

---

Björn Hornburg (ETAS)  [5:58 PM]
Hi Valery,
re 1. Yes, but the GetInstance() could also block until initialization is done.
re 2: This would not be required, if successive calls to GetInstance would also block until init is done.
re 3: See 1+2

---

Björn Hornburg (ETAS)  [1:24 PM]
Ok, then maybe I did understand something wrongly: I thought, one of your reasons to keep the Init was, that it blocks the caller until the initialization is done. Any supsequent caller would also be blocked until initialization is finished. Afterwards no further blocking.
[1:27 PM]As I would understand it, every caller of GetInstance() would also need to call Init() or needs to check the IsAvailable().
From that point of perspective, my thinking was to do everything in the GetInstance() call, i.e. "my" GetInstance() would behave like "your" GetInstance() + Init().[1:29 PM]Of course, if a clock user does not need to call Init() to avoid blocking, then my variant would change that behavior
Valery Lavrov  [1:30 PM]
not fully like that.
GetInstance - just provides an instance in any state

TryInit -> we are trying to init, it does block but just for a quite fast time. it should not wait until anything. Polling only.
there could be a blocking method, who will wait , ex WaitForInitialzation(),  - we could treat it like a blocking step.