Related
I am implementing a gen_fsm using the gen_statem module and when i am trying to check its state as a handle_event_function i get the following error:
> ** exception error: {function_clause,
> {gen_statem,call,[{ok,<0.139.0>},state,0]}}
> in function gen:do_for_proc/2
> called as gen:do_for_proc({ok,<0.139.0>},#Fun<gen.0.9801092>)
> in call from gen_statem:'-call_clean/4-fun-0-'/5 (gen_statem.erl, line 637) 25> c("C:/Erlang/Genserv/fsm.erl").
Below is my code which is separated into :
-mandatory methods for the fsm to work
-api that the client can use (state change,get the state,start)
- generic handlers for when client demands something related to state
-state implementations
Module
-module(fsm).
-record(state,{
current="None",
intvCount=0,
jobCount=0
}).
-export([init/1,terminate/3,callback_mode/0,code_change/4]).
-export([state/1,start/0,hire/2,fire/2,interview/2]).
-export([sitting_home/3,interviewing/3,working/3]).
-behaviour(gen_statem).
%API
start()->
gen_statem:start_link(?MODULE,[],[]).
state(PID)->
gen_statem:call(PID,state,0).
hire(PID,Company)->
gen_statem:call(PID,{hire,Company},0).
fire(PID,Company)->
gen_statem:call(PID,{fire,Company},0).
interview(PID,Company)->
gen_state:call(PID,{intv,Company},0).
%mandatory
code_change(V,State,Data,Extra)->{ok,State,Data}.
callback_mode() ->
[state_functions,handle_event_function].
init([])->
{ok,sitting_home,#state{current="None",jobCount=0,intvCount=0}}.
terminate(Reasom,State,Data)->
void.
% Generic handlers
handle_event({call,From},state,State)->
{keep_state,State,[{reply,From,State}]};
handle_event(_,_,State)->
{keep_state,State}.
% State implementations
sitting_home({call,From},{intv,Company},State=#state{intvCount=C})->
{next_state,interviewing,State#state{intvCount=C+1},[{reply,From,"Interviewing by:"++Company}]};
sitting_home(EventType,Event,State)->
handle_event(EventType,Event,State).
interviewing({call,From},{rejected,Company},State)->
{next_state,sitting_home,State,[{reply,From,"rejected by:"++Company}]};
interviewing({call,From},{accepted,Company},State=#state{jobCount=J})->
{next_state,
working,
State#state{jobCount=J+1,current=Company},
[{reply,From,"accepted offer from:"++Company}]
};
interviewing(EventType,Event,State)->
handle_event(EventType,Event,State).
working({call,From},{fire,Company},State=#state{current=C})->
{next_state,working,State#state{current="None"},[{reply,From,"Got fired from"++Company}]};
working(EventType,Event,State)->
handle_event(EventType,Event,State).
Usage
FSM_PID=fsm:start().
fsm:state(PID). //crashes when demanding state
fsm:hire(PID,"Some Company").
fsm:start() returns the tuple {ok,Pid}. You cannot use directly the return of the function in your next call. Instead you must do something like:
{ok,P} = fsm:start().
fsm:state(P).
Then you will experience other troubles, the first one is that you specify a timeout of 0, so you will get a timeout error. You will have to change this, and continue debugging :o)
[edit]
You don't need to specify the Pid, it is done in background by the gen_statem code, the gen_statem:call function is executed in the caller context so it still has access to the caller Pid.
In fact it is a little more complex, depending if you specify a timeout or not, the gen_statem:call/3 will spawn a process to call the gen:call/4 function or will directly call it, thus the Pid sent to the state machine will be either the spawned function's one or the caller's one.
The gen:call/4 also add a Reference in the message to the state machine to "sign" the answer and guaranty that an incoming message from any other part of the application will not be interpreted as the answer.
This is a general pattern in erlang (and programming) to hide as much as possible the system mechanism in interface function. Just as you do in the function state/1
In erlang doc:
return_to Used in conjunction with the call trace flag. Trace the
actual return from a traced function back to its caller. Only works
for functions traced with the local option to erlang:trace_pattern/3.
The semantics is that a trace message is sent when a call traced
function actually returns, that is, when a chain of tail recursive
calls is ended. There will be only one trace message sent per chain of
tail recursive calls, why the properties of tail recursiveness for
function calls are kept while tracing with this flag. Using call and
return_to trace together makes it possible to know exactly in which
function a process executes at any time.
To get trace messages containing return values from functions, use the
{return_trace} match_spec action instead.
Message tags: return_to.
What is "actual return"? I tested a tail recursive function, but it seems no difference.
Following is my test.erl:
-module(test).
-compile(export_all).
-record(state, {stacks=[]}).
test_tracer() ->
Tracer = spawn_tracer(),
erlang:trace_pattern({?MODULE, '_', '_'}, [], [local]),
erlang:trace(self(), true, [call,
arity,
return_to,
%% procs,
%% running,
timestamp,
{tracer, Tracer}]),
loop(100),
Tracer!dump.
spawn_tracer() ->
spawn(fun()-> trace_listener(#state{}) end).
trace_listener(State) ->
receive
dump ->
io:format("~p", [lists:reverse(State#state.stacks)]);
{trace_ts, Pid, call, MFA, Ts} ->
Stacks = State#state.stacks,
trace_listener(State#state{stacks=[MFA|Stacks]});
_Term ->
io:format("~p~n", [_Term]),
trace_listener(State)
end.
loop(0) -> ok;
loop(N) -> loop(N-1).
Whether there is return_to or not, it prints 101 {test,loop,1}.
I supposed that it should only return one {test,loop,1} with return_to.
No, the return_to flag doesn't disable the tail calls, it merely traces where/who the final result is returned to.
Change the code to fit to the screen:
...
loop(10),
timer:sleep(100),
Tracer ! dump.
With return_to enabled you will get the message:
{trace_ts,<0.348.0>,return_to,{test,test_tracer,0},{1405,153820,908198}}
It means the loop/1 function returned its result to test:test_tracer/0.
There's not such a message without return_to.
To get the return values you need to change the pattern:
erlang:trace_pattern({?MODULE, '_', '_'}, [{'_', [], [{return_trace}]}], [local]),
Now you will get the messages like:
{trace_ts,<0.657.0>,return_from,{test,loop,1},ok,{1405,155132,517284}}
(edit: i miss some reputation to create the bitcask tag so ...)
(tl;dr => bitcask:get/2 doesn't work and raises badarg in bitcask_nifs:keydir_get_int)
I would like to know how to use bitcask without riak the right way.
First, i was trying this:
bitcask:put(Handle, 3, {this, is, data}).
bitcask:get(Handle, 3).
This two calls raise the same error : badarg with erlang:size/1
The problem is erlang:size/1 accepts only binaries or tuples.
So i was trying this :
bitcask:put(Handle, {thing, 3}, {this, is, data}).
bitcask:get(Handle, {thing, 3}).
A new badarg error then, with erlang:crc32 and the Value i want to store.
So now i use this code, bucket is the atom name of a registered gen_server
which keeps the handle in its state. cask_wrapper is the code for theese
gen_servers. The code below is the acces to theese gen servers.
-module(sr_db).
...
get(Type, Key) when not is_binary(Key) ->
?MODULE:get(Type, term_to_binary(Key));
get(Type, Key) ->
Bucket = type2bucket(Type),
cask_wrapper:get(Bucket, {get, Key}).
put(Type, Key, Data) when not is_binary(Key) ->
?MODULE:put(Type, term_to_binary(Key), Data);
put(Type, Key, Data) when not is_binary(Data) ->
?MODULE:put(Type, Key, term_to_binary(Data));
put(Type, Key, Data) ->
Bucket = type2bucket(Type),
cask_wrapper:put(Bucket, Key, Data),
ok.
%% syncput(Type, Key, Data) -> call au lieu de cast
type2bucket(user) -> users_cask.
I use this code like this:
sr_db:get(user, 3).
%% then a call is made to cask_wrapper:get(users_cask, {get, 3}).
there are the cask_wrapper functions
get(Bucket, Key) ->
gen_server:call(Bucket, {get, Key}).
handle_call({get, Key}, _From, State) ->
Fetch = bitcask:get(State#state.handle, Key),
{reply, Fetch, State}.
I use the same mechanism with the put function. (but with gen_server:cast)
My first question is : is doing term_to_binary conversion in every call
a good practice, or is it slow ? I will have to convert back to erlang
terms the values that i fetch.
At the moment, the put operation returns 'ok'. It works. But the get
operation doesn't work yet. This is the error:
=ERROR REPORT==== 29-Jan-2012::20:21:24 ===
** Generic server users_cask terminating
** Last message in was {get,{get,<<131,97,3>>}}
** When Server state == {state,#Ref<0.0.0.353>}
** Reason for termination ==
** {badarg,[{bitcask_nifs,keydir_get_int,[<<>>,{get,<<131,97,3>>}]},
{bitcask_nifs,keydir_get,2},
{bitcask,get,3},
{cask_wrapper,handle_call,3},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}
Bitcask dir : "/home/niahoo/src/skyraiders/priv/bitcasks/users"
options : [read_write]** exception exit: {{badarg,
[{bitcask_nifs,keydir_get_int,
[<<>>,{get,<<131,97,3>>}]},
{bitcask_nifs,keydir_get,2},
{bitcask,get,3},
{cask_wrapper,handle_call,3},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]},
{gen_server,call,[users_cask,{get,{get,<<131,97,3>>}}]}}
in function gen_server:call/2
I can't figure out why it does not work and would appreciate some help.
Thank you
Bitcask expects the key and the value both to be binaries (as you already noticed).
I don't really know how fast term_to_binary/binary_to_term is, but there is really no way around it if you want to store terms on disk. You could of course roll you own code to convert you keys and values to/from binaries, but I doubt that it will be significantly fast than the builtin functions and certainly less flexible.
But at the end of the day you have to measure the profile your application, and decide if term_to_binary/binary_to_term is a hotspot in your total system. I would be very surprised if that is the case in any real application where data has to be written to disk.
Now to the error when calling sr_db:get/2. You are wrapping the key twice inside a {get, Key} tuple, once inside sr_db:get/2 and another time in cask_wrapper:get/2, but you unwrap it only once, by matching in cask_wrapper:handle_call/3.
You can immediately spot this in the error report in those two lines:
** Last message in was {get,{get,<<131,97,3>>}}
and
{gen_server,call,[users_cask,{get,{get,<<131,97,3>>}}]}}
I'm getting started with Erlang, and could use a little help understanding the different results when applying the PID returned from spawn/3 to the process_info/1 method.
Given this simple code where the a/0 function is exported, which simply invokes b/0, which waits for a message:
-module(tester).
-export([a/0]).
a() ->
b().
b() ->
receive {Pid, test} ->
Pid ! alrighty_then
end.
...please help me understand the reason for the different output from the shell:
Example 1:
Here, current_function of Pid is shown as being tester:b/0:
Pid = spawn(tester, a, []).
process_info( Pid ).
> [{current_function,{tester,b,0}},
{initial_call,{tester,a,0}},
...
Example 2:
Here, current_function of process_info/1 is shown as being tester:a/0:
process_info( spawn(tester, a, []) ).
> [{current_function,{tester,a,0}},
{initial_call,{tester,a,0}},
...
Example 3:
Here, current_function of process_info/1 is shown as being tester:a/0, but the current_function of Pid is tester:b/0:
process_info( Pid = spawn(tester, a, []) ).
> [{current_function,{tester,a,0}},
{initial_call,{tester,a,0}},
...
process_info( Pid ).
> [{current_function,{tester,b,0}},
{initial_call,{tester,a,0}},
...
I assume there's some asynchronous code happening in the background when spawn/3 is invoked, but how does variable assignment and argument passing work (especially in the last example) such that Pid gets one value, and process_info/1 gets another?
Is there something special in Erlang that binds variable assignment in such cases, but no such binding is offered to argument passing?
EDIT:
If I use a function like this:
TestFunc = fun( P ) -> P ! {self(), test}, flush() end.
TestFunc( spawn(tester,a,[]) ).
...the message is returned properly from tester:b/0:
Shell got alrighty_then
ok
But if I use a function like this:
TestFunc2 = fun( P ) -> process_info( P ) end.
TestFunc2( spawn(tester,a,[]) ).
...the process_info/1 still shows tester:a/0:
[{current_function,{tester,a,0}},
{initial_call,{tester,a,0}},
...
Not sure what to make of all this. Perhaps I just need to accept it as being above my pay grade!
If you look at the docs for spawn it says it returns the newly created Pid and places the new process in the system scheduler queue. In other words, the process gets started but the caller keeps on executing.
Erlang is different from some other languages in that you don't have to explicitly yield control, but rather you rely on the process scheduler to determine when to execute which process. In the cases where you were making an assignment to Pid, the scheduler had ample time to switch over to the spawned process, which subsequently made the call to b/0.
It's really quite simple. The execution of the spawned process starts with a call to a() which at some point shortly afterwards will call b() and then just sits there and waits until it receives a specific message. In the examples where you manage to immediately call process_info on the pid, you catch it while the process is still executing a(). In the other cases, when some delay is involved, you catch it after it has called b(). What about this is confusing?
I want to call xyz with the name of a function to be invoked.
-module(sample).
-export([xyz/1]).
xyz(Name) -> Name().
p() -> "you called p".
g() -> "you called g".
But I get the following error:
1> c(sample.erl).
./sample.erl:6: Warning: function p/0 is unused
./sample.erl:7: Warning: function g/0 is unused
{ok,sample}
2> sample:xyz('p').
** exception error: bad function p
in function sample:xyz/1
3>
It is correct that you have to export p and g. You can then use apply/3 to call it.
erlang:apply(sample, p, []).
Only fun-values are usable with the Fun(...) syntax. You are passing in an atom-value. An atom is a 'bad function' as the error message go. You could do something similar to
xyz(p) -> fun p/0;
xyz(g) -> fun g/0.
Then go ahead and call
Fun = xyz(p),
Fun()
-module(sample).
-export([xyz/1, p/0, g/0]).
xyz(Name) -> ?MODULE:Name().
p() -> "you called p".
g() -> "you called g".
1> sample:xyz(p).
"you called p"
Pattern match is the idiom to use:
-module(sample).
-export([xyz/1]).
xyz(p) -> p();
xyz(q) -> g().
p() -> "you called p".
g() -> "you called g".
If you want to be dynamic you can use a gen_event server.
Essentially what this is is a server that holds a state which consists of key/function pair like so:
[{p, #func1},
{g, #func2},
{..., ...},
...]
You can then essentially bind events to functions. (there is, needless to say, a bit more to it than that.
The easiest way to do is to try exporting p and g along with xyz.
-export([xyz/1, p/0,g/0]).
After exporting the function p and g can be called as follows :
1> sample:xyz(fun sample:p/0).
"you called p"
2> sample:xyz(fun sample:g/0).
"you called g"
Another way to look at it is that (depending on the problem you're solving) dynamic calls to functions isn't necessarily the right approach. Given that processes and message passing are the way you organize your code in Erlang since it's a "concurrency oriented language", maybe you could just use message passing with a selective receive rather than mimicking idioms of a sequential language? Send a message for what you want and get the custom reply based on that. It's about the result of each function, not the function itself, after all. (Plus there's the flexibility and scalability of message passing, etc.)
Although processes aren't totally free compared to calling from a library module, Erlang-level processes are dirt cheap (especially if the message communication is within the same node). They're not OS-level processes. The overhead would be comparable (or better) to dynamic function calls and object instantiation in heavier scripting languages.