tags:

views:

176

answers:

2

I have event manager process that dispatches events to subscribers (e.g. http_session_created, http_sesssion_destroyed). If Pid is used instead of named process, I must put it into functions to operate with event manager but if Named process is used, code will be more clear.

Which variant is right?

Thank you!

+2  A: 

If you have a fixed set of "subscriber" processes, then use registered names IMO.

If, on the contrary, you have a publish/subscribe sort of architecture where subscribers come and go, then you need an infrastructure to track those and from this point it doesn't really matter if you use Pid() or names.

One of the drawbacks of using registered names is that you need to track them in your code base to avoid "collisions". So it is up to you: personally, I tend to favor named processes as, like you say, it makes reading the code clearer. One way or another, OTP doesn't care.

jldupont
care to explain the downvote?
jldupont
+6  A: 

While there is no actual difference to the process naming a process, registering it, makes it global. You in essence you are telling the system that here is a global service which anyone can use.

From you description it more sounds like you are giving them names to save the, small, effort of carrying them around in your loop. If this is the case I would put their pids in a record with all the other state data you carry around. This much better indicates the type of the processes.

rvirding
By carrying the event manager reference in a record in your state you can still use an atom for the registered name in that field. So if the event manager crashes and is restarted taking the name again, you will automatically send events to the newest manager. You only risk a badarg exception if messaging it during the event manager's downtime.
Christian
Of course you can. I still don't like giving things global names if they aren't meant to be globally referenced, I can't tell from the original question whether this is so.
rvirding