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

[Steve Lhomme]

On 2020-08-31 19:43, Pierre Ynard via vlc-devel wrote:
> 
> Subject:
> Re: [vlc-devel] [RFC 0/2] New executor API
> From:
> Pierre Ynard <linkfanel at yahoo.fr>
> Date:
> 2020-08-31, 19:43
> To:
> vlc-devel at videolan.org
> 
> To:
> vlc-devel at videolan.org
> 
> 
>> 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.
> 
> I have. The tasks were chained. Apparently it worked, much better than
> the previous code.

Not only I have, too. But that's the only way I've ever used. But that 
was in Java which has a garbage collector, so a different management of 
resources. Also I never had to care about canceling tasks. The only use 
case to cancel pending jobs was just before app shutdown, and you can 
always shutdown the whole executor and it will take care of pending tasks.

I think the preparser is a good candidate of "launch tasks, I don't care 
what happens to them".

Some Medialibrary tasks like "rename a file and update the database 
after" is another example of chaining tasks which the caller doesn't 
care about what happens in the end.

There still needs to be some resource management like 
file/database/socket locking, but that doesn't have to be in the owner 
(in can but the design should not force it).