[erlang-questions] Ideas for a new Erlang

Christian S chsu79@REDACTED
Wed Jun 25 17:49:08 CEST 2008


>  > A single process can only process the mailbox
>  > sequentially. Ideally, if you got a bottleneck there, throw more
>  > processes at it (i.e. cpu cores), make it scale!
>
> Searching the mailbox in parallel? Note that we still need to
> determine which message is the first in the mailbox that
> matches. Also, if we can do without selective receive, this is a
> problem that does not need to be solved.

No, having more consumers each scanning their own mailboxes.
Distributing the load over multiple consumers.
More consumer processes in itself is a good thing, since one can make
use of concurrency to a higher degree.

My own thoughts about first class mailboxes have been around the lines of:

First, introducing erlang:self/1 so that Pid = self(worker) can be
handed out. Second, follow the grammar of exception types, but applied
to receive:

loop(Status) ->
  receive
    worker: {available, Worker} ->
      addWorker(Status, Worker);
    true: {job, Job} ->
      dispatch(Status, Job)
  end.

I'm pretending that the above implements a load balancer where workers
register that they're available to consume a job and communicate this
on a Pid made with "self(worker)".  Pids from self(true) would be the
same as self(). The receive clause allows scanning of the hopefully
shorter worker mailbox first, not having to wade through jobs to be
dispatched until messages from workers have been processed.

I wonder what can of worms the above would open.



More information about the erlang-questions mailing list