Erlang でプロセスにアクセスする方法は 2 つしかありません: その Pid (およびプロセスがあると予想されるノード) を知っているか、登録された名前 (および予想される erlang ノード) を知っているかのいずれかです。
appmod があるとしましょう:
-モジュール (myappmod)。
-エクスポート ([out/1])。
-include("PATH/TO/YAWS_SERVER/include/yaws_api.hrl")。
-include("PATH/TO/YAWS_SERVER/include/yaws.hrl")。
out(引数) ->
case check_initial_state(Arg) の
不明 -> create_initial_state();
{OK,値}->
UserPid = list_to_pid(値),
ユーザーピッド ! extract_request(引数),
受け取る
レスポンス -> {html,format_response(レスポンス)}
?タイムアウト後 -> {html,"request_timedout"}
終わり
終わり。
check_initial_state(A)->
CookieObject = (A#arg.headers)#headers.cookie,
case yaws_api:find_cookie_val("InitialState", CookieObject) の
[] -> 不明;
クッキー -> {ok,クッキー}
終わり。
extract_request(Arg)->
%% POST Data または Get Data からリクエストを取得
Post__data_proplist = yaws_api:parse_post(引数),
Get_data_proplist = yaws_api:parse_query(引数),
%% 他の多くのことを行います....
リクエスト = remove_request(Post__data_proplist,Get_data_proplist),
リクエスト。
この単純なセットアップは、プロセスを使用してユーザーに関する情報を保持する方法を示しています。ただし、プロセスの使用は適切ではありません。プロセスは失敗するので、プロセスが保持していたデータを回復する方法が必要です。
より良いアプローチは、ユーザーに関するデータ ストレージを用意し、ルックアップを行う gen_server を 1 つ用意することです。を使用できますMnesia
。Web 上のプロセスを使用してユーザーの状態を維持することはお勧めしません。それがメッセージング アプリであっても、実行しているアプリの種類に関係ありません。Mnesia またはETS
テーブルは状態を保持でき、ルックアップするだけで済みます。
プロセス以外の状態を保持するには、より優れたストレージ メカニズムを使用します。プロセスは障害点です。また、Cookie (および/またはセッション Cookie) を使用するものもあります。その値は、データベースから何かを検索するために何らかの方法で使用されます。ただし、プロセスが必要だと主張する場合は、プロセスの PID または登録名を覚えておく方法を用意してください。ユーザーPidをセッションCookieなどに保存できます