[erlang-questions] Restarting processes

[Daniel Ginsburg]

Thanks for the detailed explaination!

Ulf Wiger пишет:
> 
> 
> 2007/3/29, Daniel Ginsburg <dg@REDACTED <mailto:dg@REDACTED>>:
> 
>     This sounds good. I think I'll give it a try. I just hope that process
>     registry won't die ;)
> 
> 
> 
> Actually, the way it's written, the registry process may die, and
> will recover completely when restarted. There's another process
> which keeps the ets tables of the registry. It may not die, but
> on the other hand, there's no reason why it should, since it
> doesn't do anything. In the event that it would be killed, its
> supervisor is rigged so that it also terminates. If the proc
> application has been started as 'permanent', the erlang node
> will terminate. This is a common way to handle processes that
> mustn't die.
> 
> (I just noticed that you had seen this already.)
>  
> 
>     I think I'll need to measure performance of lookups in (or folding
>     through) the registry (if you have any data, please share). Anyway,
>     even
>     if the lookup is not very fast, I'll be able to repopulate demux lookup
>     tables from the registry in case demux has to restart.
> 
> 
> Performance is not as good as with the built-in registry, but a
> registration
> will take somewhere around 30-60 microseconds, depending on what
> machine you're using. The fold operation is cheap - essentially an
> ets:select
> on an ordered_set ets table. This means that if the beginning of the select
> pattern is bound (which will be the case when you fold over a known
> property),
> the search time will be proportional to the number of such properties in
> the registry, almost independently of how many other properties there are.
> 
> In our in-house version, we've made some optimizations - mainly an
> add_properties/1 function, where several properties are registrered
> using only one gen_server call. The cost of registering e.g. 10 properties
> at once is only marginally higher than the cost of registering one property.
> 
> A colleague of mine made the further optimization of saving a set of
> properties as bits in a counter. Then, adding a property was reduced to
> an update_counter() operation. To make full use of this, we also added
> a fold_counters() function.
> 
> I don't have time to port these additions to the jungerl version, but they
> are fairly trivial to add, should someone else feel like doing so.
>  
> BR,
> Ulf W
> 


-- 
dg