diff options
| author | Michal Minar <miminar@redhat.com> | 2013-12-12 13:10:36 +0100 |
|---|---|---|
| committer | Michal Minar <miminar@redhat.com> | 2013-12-12 15:04:10 +0100 |
| commit | 2b22e2975cd12852ee9931e472cc85e7b42e65a0 (patch) | |
| tree | fddd67cab2348bef14bee8d2fa693c7e89565ea1 /src/python | |
| parent | 0ff1628666bc2ad52da91297c55a59d10b077e4e (diff) | |
software: redone job handling
There was a serious flaw in previous object model. JobManager was a
thread spawned from inside of separated YumWorker process. Meanwhile
IndicationManager was spawned in provider process which is correct
otherwise it coult not send indications through broker.
The problem is that JobManager needs to create indications and access
IndicationManager. But they were in different processes.
JobManager worked with static data duplicated from provider process when
the worker process has been forked. Therefor all subscriptions and
indication enablement made after the worker processed has been
created did not affect jobmanager.
For some unknown reasons this could also cause a segfault to worker
process when creating indications that were sent to provider process.
This patch shuffles classes a bit:
* JobManager is spawned as a thread in provider process by YumDB.
* JObManager spawns its own SessionManager that is a wrapper for
YumWorker process
* SessionManager is a thread running in provider's process. It
manages worker process and ensures that yum database is locked when
there is an active session.
* YumWorker does not spawn any other process. It processes jobs one by
one.
Resolves: #1039018
Diffstat (limited to 'src/python')
0 files changed, 0 insertions, 0 deletions
