[erlang-questions] Restricting number of executions per second

[Ahmed Ali]

Hi,

Thanks both for your prompt answer. Actually, it turned out, the
transactions takes almost the same time to complete, so a simple
timer:sleep(1000/n) before calling the function suffice.

However, this is an interesting question. Sometimes, we need to
restrict throughtput (e.g. QoS) and I'd like to know how people solve
similar actions. I didn't have to think about this before.

The solution that I can think of now is to have a process (pool of
processes?) to control access a channel. The entry point is something
like the pseudo-function send_msg/1 below (assuming asyc type
messages). I'm sure this has been discussed before so if someone can
provide me with a link, I'd appreciate it.

send_msg(Msg) ->
    case is_free() of
        go_ahead ->
            gen_server:cast(?MODULE, Msg);
        _ ->
            add_msg_to_queue(Msg)
    end.

handle_cast(Msg, From, State) ->
    State2 = do_something(Msg),
    %% spawn so that function returns
    spawn(fun send_msg_from_queue/0),
    {reply, ok, State2).

send_msg_from_queue() ->
    Msg = remove_from_queue(),
    gen_server:cast(?MODULE, Msg).

Best regards,

Ahmed

On Wed, Dec 3, 2008 at 6:13 PM, Bengt Kleberg
<bengt.kleberg@REDACTED> wrote:
> Greetings,
>
> One way to do it could be to add the frequency of calls to the server
> state. Too high frequency => do not call the function.
>
>
> bengt
> On Wed, 2008-12-03 at 17:41 +0400, Ahmed Ali wrote:
>> Hi All,
>>
>> I want to run a function in not more than a specific numbers of times
>> per second (e.g. 3 times per second). The function is part of a
>> gen_server process (i.e. called using gen_server:call/2). What's the
>> best way to do this?
>>
>> The funny thing is that the first idea I got for a solution is locking
>> n semaphores to serialize the execution. I guess I'm still locked in
>> the mainstream paradigm :)
>>
>> Best regards,
>>
>> Ahmed
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>