The design choice of EventStorage

[jizongFox]

Hello,
I am quite interested in the design choice of EventStorage(...), where you rely heavily on the context manager.
In the enter, you register the class to a stack and when exit, you remove it. The whole usage would be enveloped by a with statement:

with EventStorage(...) as self.storage:
    ....

in the trainer.
I am wondering what is the motivation of this design. I can just define a self.storage = EventStorage(...) in the init of a trainer. What is the concern behind the stack-based solution?

Best,
Jizong

[ppwwyyxx]

This allows the current eventstorage to be accessible through https://detectron2.readthedocs.io/en/latest/modules/utils.html#detectron2.utils.events.get_event_storage

[jizongFox]

Thanks for this information. I am aware of this function. Compared with defining self.storage = EventStorage(..) and you can have access of self.storage within the loop, what is the advantage of using a separated function get_even_storage?
My intuition is that this get_event_storage can be accessible in the code other than the trainer loop (under with envelope). Can you provide more insight on that?

[ppwwyyxx]

My intuition is that this get_event_storage can be accessible in the code other than the trainer loop

Yes. You can find where it is accessed: https://github.com/facebookresearch/detectron2/search?q=get_event_storage

[jizongFox]

Thanks for the reply, however, get_event_storage function can only get the lastest storage while if there are multiple storages nested in the following structure:

with EventStorage(..)  as self.storage1:
    # store something inside self.storage1
    with EventStorage(..)  as self.storage2:
          # store something else inside self.storage2

How to get the correct storage outside of the trainer?