reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Weimer <mar...@weimo.de>
Subject Re: REEF Services
Date Tue, 16 Feb 2016 17:13:20 GMT
On 2016-02-12 11:40, Andrew Chung wrote:
> My understanding is that they are just a set of injectable objects
> that don't necessarily have anything in common.

Correct. That name is misleading, not my finest hour in naming things :)
As the introduction of Services pre-dates the Open Source release of
REEF, let me add a bit of back story:

Services are meant to be the extension hooks the API of the Driver and
the Evaluators. Tang solves much of this, as one can just merge
`Configuration` for additional libraries to the Driver / Evaluator
`Configuration` and then depend on instances from those libraries.

On the Driver, this is really all we need, as there is only one Driver
and the life cycle of the Service completely matches the one of the Driver.

On the Evaluator, the story got more tricky: The Evaluator's life cycle
is decoupled from the Task life cycle. There is no guarantee that
subsequent Tasks will need the same Services. Some Services may be
detrimental to the performance of one Task, while required by another.
Think of caching layers which occupy lots of memory as an example. Even
worse, some Services are incompatible with one another (version hell).
Hence, we can't bind Services to the Evaluator's life cycle.

But we can't bind them to the Task life cycle either: There is no
guarantee that subsequent Tasks on the same Evaluator do not need the
same Services either. And important state might be lost if we cleared
out the Services in between Tasks.

Hence, we need a way to control the life cycle of these Services
independently of the Evaluator and the Task: Contexts. Mind you,
Services on the Evaluator are just what they are on the Driver:
injectable instances.

However, we now need to control the singleton property of these objects.
Logically, a Service should be a singleton for the duration of a
Context. In order to make that happen, we need to instantiate them
before the Task gets instantiated. In order to do this, we need an
enumeration of the classes considered part of the Service, hence the
`ServiceConfiguration`: Its main purpose is to tell the Evaluator which
objects it shall instantiate before the Task and hang onto in between
tasks. That is the only thing distinguishing a Service from any other
injectable object.

Long story short: There is no need for them to all implement a common
base interface. Or that need hasn't come up yet :)

Markus

Mime
View raw message