State in OTP event manager process (not handler!)

Question

Can an OTP event manager process (e.g. a logger) have some state of its own (e.g. logging level) and filter/transform events based on it?

Answer 1

I also have a need to put some state into the gen_event itself, and my best idea at the moment is to use the process dictionary (get/put). Handlers are invoked in the context of the gen_event process, so the same process dictionary will be there for all handler calls.

Yes, process dictionaries are evil, but in this case they seem less evil than alternatives (ets table, state server).

Answer 2

The gen_event implementation as contained in the OTP does no provide means for adding state. You could extend the implementation to achieve this and use your implementation instead of gen_event. However I would advise against it.

The kind of state you want to add to the event manager belongs really in the event handler for several reasons:

• You might want to use different levels in different handlers, e.g. only show errors on the console but write everything to the disk.

• If the event level would be changed in the manager event handlers depending on getting all unfiltered events might cease to function (events have more uses than just logging). This might lead to hard to debug problems.

• If you want a event manager for multiple handlers that all only get filtered events you can easily achieve this by having two managers: one for unfiltered messages and one for e.g. level filtered messages. Then install a handler to the unfiltered one, filter in the handler by level (easy) and pass on the filtered events to the other manager. All handlers that only want to get filtered messages can be registered to the second manager.

The handlers can have their own state that gets passed on every callback like:

Module:handle_event(Event, State) -> Result

Filtering might look like this (assuming e.g. {level N, Content} events):

handle_event({level, Lvl, Content}, State#state{max_level=Max}) when Lvl >= Max ->
     gen_event:notify(filtered_man, Content);

The State can be changed either by special events, by gen_event:call\3,4 (preferably) or by messages handled by handle_info.

For details see Gen_Event Behaviour and gen_event(3)

Answer 3

When you start_link a gen_event process - thing that you should always do via a supervisor -, you can merely specify a name for the new process, if you need/want it to be registered. As far as I can see, there's no way to initiate a state of some sort using that behaviour.

Of course, you can write your own behaviour, on the top of a gen_event or of a simple gen_server.

As an alternative, you might use a separate gen_event process for each debugging level. Or you can just filter the messages in the handlers.