[erlang-questions] Process swarm vs Queues

[lud]

Hi,

> Your problem seems very under-defined.  In particular, we don't know
> the overhead of processing an event, or what you're trying to optimize
> (latency? throughput? robustness?).  The processes that want to monitor
> resources, is that the external API to your system or an implementation
> detail within your system?

It is not (yet) about optimizing but rather about how to chose a 
particular
design around state and concurrency.

My example is simple and anyone here can implement all the possible 
solutions,
but it is not obvious to me why a specific solution is the best.

> Anyway, since you mention reading and writing state to disk around each
> handled event, minimizing latency cannot be critical.  Therefore I 
> don't
> see the need for anything complicated here: just spawn a temporary 
> process
> for each event as it occurs.  If you need serialization, add a 
> gen_server.
> If state is precious, have a supervisor own it.
> 
> Don't overengineer unless you have proof that the simple solution 
> doesn't
> work.

At the moment, I have event handlers processes register properties on 
gproc to
be notified about the resources they monitor. I can directly send the 
event
via the pub/sub feature of gproc.

To use a queue or spawn a process, I would need an ETS table registering 
the
handler ID with the ressource, to be able to spawn a handler with the
appropriate state.

So I'll follow your advice and keep it simple, finish the work, and see 
if the
RAM is a problem.

Thank you :)