                                                                                                                                                                                                                                                                
Received-SPF: pass (google.com: domain of erlang-questions-boun...@erlang.org designates 192.121.151.104 as permitted sender) client-ip=192.121.151.104;
MIME-Version: 1.0
In-Reply-To: <022F4CD3-4A8F-4B38-8A5B-41A484B00...@gmail.com>
References: <022F4CD3-4A8F-4B38-8A5B-41A484B00...@gmail.com>
Date: Thu, 11 Oct 2012 20:08:26 +0200
Message-ID: <CAANBt-rcZ_1E-CZAwYBqkmZYh75aa=k6j74w5CAmSw4BXeU...@mail.gmail.com>
From: Joe Armstrong <erl...@gmail.com>
To: Eric Newhuis <enewh...@gmail.com>
Cc: erlang-questi...@erlang.org
Subject: Re: [erlang-questions] Bounded Buffer Problems/Solutions
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: erlang-questions-boun...@erlang.org
Sender: erlang-questions-boun...@erlang.org

On Wed, Oct 10, 2012 at 9:37 PM, Eric Newhuis <enewh...@gmail.com> wrote:
> What are the generally accepted solutions for when producers need to be throttled?  gen_server as consumer or otherwise?
>
> Are there any good solutions or philosophy for the bounded buffer problem in Erlang?  ..flow control?  Freaky out-of-band communication at a distance to limit messages sent?  Use the idea of rope:  Message in reverse to a producer shim that he is allowed to send N more messages before he needs to ask for the right to send more?  Other?

Actually no - we noticed years ago (round 1990) that if producers ran
faster than consumers
you got a problem. So it this case we made everything synchronous.
Send a message, wait for a reply
ad nauseam. This is used in gen_servers and virtually everywhere. It
doesn't seem to matter
I guess if the CPU is always busy we're happy bunnies. Ok so you wait
a bit longer, bit something else gets done while you're waiting.

Now you could (say) require an ack after every ten messages - and send up to ten
messages without requiring an ack or something but things actually go
surprisingly well
without this ...


>
> Are there common Erlang idioms for monitoring execution time at the gen_server level so that an API can respond upward with a policy of "the system is currently busier than a one legged man in a kicking contest?"

No - easy to implement though.

My approach has always been take the simplest solution that works -
then measure and
only fix things if they are broken.

So we've built massive systems with synchronous client server RPCs all
over the place
then we tune them - most often it's the time to parse inputs or the
database that's the problem.

Getting data in and out of the system and computation seem to be the
problem areas
the interprocess message passing is very fast compared to this - so
complex buffering seems
not to be necessary.

I'm not saying you never need it - just that I've never seen it myself.

Cheers

/Joe

>
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions