Bug #896: MapPyGroup birth and death - MAUS - MICEmine

Bug #896

MapPyGroup birth and death

Added by Jackson, Mike almost 12 years ago. Updated over 11 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Rogers, Chris

Category:

common_py

Target version:

MAUS-v0.1.4

Start date:

07 February 2012

Due date:

% Done:

100%

Estimated time:

Workflow:

Closed

Description

A possible issue?

At present MapPyGroup.death does:

        try:
            for worker in self._workers:
                assert worker.death()
        except: # pylint:disable = W0702
            return False
        return True

This means that if death of one sub-worker fails, then death won't be called on subsequent workers? Is this an issue? Will it matter that the subsequent ones won't be @death@d and possibly do their clean-up?

Updated by Tunnell, Christopher almost 12 years ago

For offline user-mode, it was just meant to crash and burn so people actually noticed that death failed. If death fails then something very wrong has happened...

For online running, we want to keep running so will want to 'death' as much as possible. We could just set an 'error' bit, do try-catch, if exception then error := 1 but continue 'death'ing workers. Then the function returns not(error)? Then go can choose what to do.

But I agree that complicated logic should be avoided in MapPyGroup: it should kill all it can, then notify how well it did.

Updated by Rogers, Chris almost 12 years ago

Category changed from Online reconstruction to common_py
Assignee changed from Tunnell, Christopher to Rogers, Chris

I can do it if you want...

Updated by Rogers, Chris almost 12 years ago

Also, in del I notice that it always deaths the workers. What if I have multiple instances? Should be that we death() only if this is the last reference (i.e. death works like a normal python destructor)