[erlang-questions] On selective receive (Re: eep: multiple patterns)

[Andreas Hillqvist]

Thank you for your answer.

For sending I was thinking that it would be possible to use the Queue
Identifyer (somthing similar to a PID):
      Queue ! Message

And that Queue are only linked to process.


One possebility with Multiple Queues is that it would be possible to
Prioritize messages more efficiently:
 * If there is a message in Queue read messsage, else repeat for next Queue.
 * If there is no message in any Queue, wait for a message from any Queue.

It might be nice to have one Queue for system messages and such.


I do not know if the Multiple Queues is the right path.
It would be possible to build some of the functionality with helper
process for Queue.

And that could be part of the framework you mentioned and let the
future decide if the Multiple Queues semantics will catch on.

It might then be omre efficently be implemented in the Erlang Runtime.


Kind Regards
Andreas Hillqvist


2008/6/4, Vlad Dumitrescu <vladdu55@REDACTED>:
> On Wed, Jun 4, 2008 at 8:46 AM, Andreas Hillqvist
> <andreas.hillqvist@REDACTED> wrote:
> >
> > What if it would be possible to create Message Queues in addition to
> > process "default" Message Queue?
> >
> >
> How would you send messages? Something like
>     {Pid, Queue} ! Message
> ?
>
> Since the sender will have to know which queue to send to, this is no
> different than having a cluster of processes that cooperate (from the
> client's point of view). Possibly it would be somewhat easier to code the
> server, but it could get hairy too...
>
> Maybe if this would be combined with Richard O'Keefe's suggestion for
> filtered receive statements: each queue has a filter and messages are
> automagically added to the right queue (by the runtime), without the client
> having to care about this implementation detail... But then the server
> process must juggle with the different queues anyway and my first impression
> is that it won't get easier to understand what's happening.
>
> Personally, I would rather have some kind of framework that would help
> manage the cluster of processes mentioned above. I feel it would be much
> easier to get right and debug.
>
> regards,
> Vlad
>
>