celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [celix] pnoltes opened a new pull request #316: Initial executor abstraction to promise
Date Mon, 01 Feb 2021 15:30:54 GMT

pnoltes opened a new pull request #316:
URL: https://github.com/apache/celix/pull/316


   This PR introduces a Executor abstraction and makes an initial interface for a ScheduledExecutor.

   
   These changes remove the need for a concrete thread execution library on Celix Promise
level, and
   as result the dependency to TBB has been removed. 
   Execution library can be plugged in by provided a implementation of celix::IExecutor (and
in the future celix::IScheduledExecutor).
   the Celix promise library also provides a default - and simple - executor implementation
based on sdt::async.
   
   Although the Celix promise implementation tries to follow the OSGi Promises (and as result
Java Executor/ScheduledExecutorService) as much as possible. This PR does introduces some
differences:
   
   1. There is no singleton default executor. A PromiseFactory can be construction argument-less
to create a default executor, but this executor is then bound to the lifecycle of the PromiseFactory.
If celix::IExecutor is injected in the PromiseFactory, it is up to user to control the complete
lifecycle of the executor (e.g. by providing this in e ThreadExecutionModel bundle and ensuring
this is started early (and as result stopped late). 
   2. The default constructor for celix::Deferred has been removed. A celix:Deferred can only
be created through a PromiseFactory. This is done because the promise concept is heavily bound
with the execution abstraction and thus a execution model. Creating a Deferred without a explicit
executor is (IMO) not logical.
   3. The PromiseFactory also has a deferredTask method. This is a convenient method to a)
create a Deferrerd, b) start a task (with the Deferred as argument) on the executor of the
PromiseFactory, and c) return the Promise of the just created Deferred. 
   4. The celix::IExecutor abstraction has a priority argument (and as result also the calls
in PromiseFactory, etc). Although currently not used, IMO a priority argument when starting
a Promise chain is a logical wish for a C++ environment. Again note that Promises are heavily
bound to the thread execution model. 
   5. The IExecutor has a added wait() method. This is useful when testing and possible task
are still on the executor backlog and to explicitly control the tasks backlog when exiting
a process. But this is also needed to prevent circular references between the SharedPromiseState
and IExecutor impl. If the process exists when there are still task in the executor, this
will lead to mem leaks. 
   
   I am not yet sure how the handle the ScheduledExecutor abstraction. A promise can only
use this on 2 points: Promise::delay and Promise::timeout and in those 2 cases, only the timeout
would benefit from a cancelable ScheduledFuture abstraction. So is the complexity of a scheduleWithFixedDelay
and scheduleWithFixedTimeout needed. Or is extending the IExecutor abstraction with a canceable
scheduleWithDelay enough for the Celix Promise library. 
   
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



Mime
View raw message