Make sure metric handlers are fired first

Hi,

I noticed that since event handlers are invoked at the order of their insertion, there’s a potential bug- if a metric handler is inserted after a TensorBoard handler, the metric value will not be ready at the time of writing.

While this has only minor effects (one epoch shift in the results), I think it can be easily solved by one of two approaches:

1. separating handlers list to two: one for metrics, and the other handler types.
2. More generic and scalable- allowing users to decide the order of execution by adding priority argument to add_event_handler (default would be that metric handlers are inserted with higher priority) and then sort the list when run() is invoked.

Let me know if you like any of the ideas, and I’d be happy to draft a PR

[justusschock]

I think this is a general question. We should decide, whether we want priorities/sorting of handlers or not (but definitely not support both versions).

If we implement it, it should always be used, but this may also introduce unwanted behaviour if some handlers are for example added by an internal function with a different priority, this may also confuse the user, since he might expect some other behaviour.

I think, I slightly prefer the way including priorities, but this has to be carefully implemented. On the implementation side, I would prefer to have the priority option not in the function adding the handler but as an attribute of the handler (comparable to the logging level in python’s internal logging module).

[justusschock]

Yes it requires a new handler class but also some code that allows all current handler implementations to continue working by providing good defaults and wrapping possibilities