[vlc-devel] [RFC 0/2] New executor API

[Rémi Denis-Courmont]

Le maanantaina 31. elokuuta 2020, 9.34.12 EEST Steve Lhomme a écrit :
> > Yes exactly. All the complexity comes from the very disagreeable decision
> > to have the runner rather than the owner keep track of the tasks. If the
> > owner keeps track of its tasks, it can interrupt them (due to stop or
> > time-out) directly, and the tasks can notify their complexition directly
> > as well.

> IMO that's the runner dealing with what happens to the task is the more
> generic way, which allow more use cases.

Obviously the runner needs to track what task is waiting to be run. Point is 
that the respective owner of each task should track their pending tasks.

I've never seen a scheduler where task owners just forgot their tasks and let 
the scheduler track the task on behalf of the owners. That misses separation 
of concerns. Besides I can't see how it works - the owner needs to expect the 
result of their queued tasks. For instance, if they're futures, it needs a 
reference to those futures.

> If you tie a task to an owner, it forces the owner to do all kind of things

Like what? And how do you not tie a task to its owner?! At some point you need 
a concrete implementation of something.

The owner needs to know what tasks it's queued. That's just common sense. I've 
seen many task management APIs in C. None really allow the owner to just 
forget about their own "children" tasks.

And typically, delivering the results is one of:

- the owner waits explicitly for completion (no callback involved),
- the task is tied to the owner and just does the needful (again no callback 
involved),
- or the above layer has a callback mechanism to deliver the result, not the 
runner. The callback mechanism itself may be a separate abstraction or it may 
just be a type-specific bespoke callback.

(...)

> One use case we could use in the future is chaining tasks.

There are no reasons why a future abstraction would be tied to the runner 
abstraction. Also what Alexandre already point out...

I however doubt that futures would make much sense in VLC. C cannot provide 
the syntactic sugar to make them nice, nor the coroutines to make them 
efficient. We also don't have a generic mean to wait on multiple futures.

-- 
Rémi Denis-Courmont
http://www.remlab.net/