[ACCEPTED]-Erlang - spawning processes and passing arguments-erlang

Accepted answer
Score: 13

actually Richard pointed me in the right 8 direction to take to avoid the issue nicelly 7 (in a reply to the same post I put up on 6 the Erlang GoogleGroups): http://groups.google.com/group/erlang-programming/browse_thread/thread/1d77a697ec67935a

His answer:

By "using 5 closures", I hope you mean something 4 like this:

Pid = spawn(fun () -> any_function(Any, Number, Of, Arguments) end)

How 3 would that be limiting to your code structure?

 /Richard 

thank 2 you for promptly commenting you my question. Much 1 appreciated

Score: 2

Short answer: you can't. Spawn (in all 10 it's varying forms) only takes a 0-arity 9 function. Using a closure and bringing 8 in bound variables from the spawning function 7 is the way to go, short of using some sort 6 of shared data store like ETS (which is 5 Monster Overkill).

I've never found using 4 a closure to severely hamper my code structure, though; can 3 you give an example of the problems you're 2 having, and perhaps someone can tidy it 1 up for you?

Score: 2

This is an old question but I believe it 24 can be properly answered with a bit of creativity:

The 23 goal of the question is to

  • Invoke a function

With the following 22 limits;

  • No M:F/A formatting
  • No exporting of the Invoked function

This can be solved in the following;

Using 21 the 1st limitation leads us to the following 20 solution:

run() ->
    Module = module,
    Function = function,
    Args = [arg1, arg2, arg3],
    erlang:spawn(Module, Function, Args).

In this solution however, the function 19 is required to be exported.

Using the 2nd 18 limitation (No exporting of the Invoked function) alongside the 1st leads us 17 to the following solution using conventional 16 erlang logic:

run() ->
    %% Generate an anonymous fun and execute it
    erlang:spawn(fun() -> function(arg1, arg2, arg3) end).

This solution generates Anonymous 15 Funs every execution which may or may not 14 be wanted based on your design due to the 13 extra work that the Garbage Colelctor will 12 need to perform (note that, generally, this 11 will be neglible and issues will potentially 10 only be seen in larger systems).

An alternative 9 way to write the above without generating Anonymous 8 Funs would be to spawn an erlang:apply/2 which can execute 7 functions with given parameters.

By passing 6 a Function Ref. to erlang:apply/2, we can reference a 5 local function and invoke it with the given 4 arguments.

The following implements this 3 solution:

run() ->
    %% Function Ref. to a local (non-exported) function
    Function = fun function/arity,
    Args = [arg1, arg2, arg3],
    erlang:spawn(erlang, apply, [Function, Args]).

Edit: This type of solution can 2 be found within the Erlang Src whereby erlang:apply/2 is being called 1 to execute a fun() with args.

%% https://github.com/erlang/otp/blob/71af97853c40d8ac5f499b5f2435082665520642/erts/preloaded/src/erlang.erl#L2888%% Spawn and atomically set up a monitor.

-spec spawn_monitor(Fun) -> {pid(), reference()} when
      Fun :: function().
spawn_monitor(F) when erlang:is_function(F, 0) ->
    erlang:spawn_opt(erlang,apply,[F,[]],[monitor]);
spawn_monitor(F) ->
    erlang:error(badarg, [F]).
Score: 0

first, there is no code and we can't help 6 you a lot, so the best way to control your 5 functions and their args with your spawned 4 processes is to spawn the process with a 3 receive function then you will be in contact 2 with your process across the send and receive 1 method, try:

Pid=spawn(Node, ModuleName, functionThatReceive, [])
%%or just spawn(ModuleName....) if the program is not %%distributed
Pid ! {self(), {M1, f1, A1}}, 
receive
{Pid, Reply} ->Reply
end, 

Pid ! {self(), {M2, f2, A2}}, 
receive
{Pid, Reply} ->Reply
end, 
....... 
functionThatReceive() ->
receive
{From, {M1, f1, A1}} ->From ! {self(), doSomething1} ;
{From, {M2, f2, A2}} ->From ! {self(), doSomething2} 
end. 

More Related questions