شماره‌ی نوبت دلوکس

GenServer

GenServer (سرور عمومی) یک «رفتار» است که تعاملات رایج کلاینت-سرور میان فرایندهای Elixir را انتزاع می‌کند.

«حلقه‌ی دریافت» را از زمانی که درباره‌ی فرایندها یاد گرفتیم به خاطر دارید؟ «رفتار» GenServer انتزاع‌هایی برای پیاده‌سازی چنین حلقه‌هایی فراهم می‌کند و امکان تبادل پیام با فرایندی را می‌دهد که چنین حلقه‌ای را اجرا می‌کند. این کار نگه‌داری وضعیت و اجرای کد ناهمگام را آسان‌تر می‌کند.

«رفتار» GenServer یک کال‌بک الزامی، init/1 و چند کال‌بک اختیاری جالب تعریف می‌کند: handle_call/3، handle_cast/2 و handle_info/3. کلاینت‌هایی که از یک GenServer استفاده می‌کنند قرار نیست آن کال‌بک‌ها را مستقیماً فراخوانی کنند. در عوض، ماژول GenServer توابعی فراهم می‌کند که کلاینت‌ها می‌توانند با آن‌ها با یک فرایند GenServer ارتباط برقرار کنند.

اغلب یک ماژول واحد هم یک API کلاینت تعریف می‌کند و هم پیاده‌سازی‌های کال‌بک سمت سرور. API کلاینت مجموعه‌ای از توابع است که بخش‌های دیگر برنامه‌ی Elixir شما می‌توانند برای ارتباط با این فرایند GenServer آن‌ها را فراخوانی کنند. پیاده‌سازی‌های کال‌بک سمت سرور هم منطق این GenServer را در خود دارند.

بیایید اول به یک مثال ساده از GenServer نگاه کنیم و بعد ببینیم هر کال‌بک چه معنایی دارد.

مثال

این یک سرور نمونه است که می‌تواند در یک سفر جاده‌ای طولانی به پرسش‌های مکرر مسافران آزاردهنده پاسخ دهد؛ دقیق‌تر بگوییم، به این پرسش: «رسیدیم؟». تعداد دفعاتی که این پرسش پرسیده شده را پیگیری می‌کند و پاسخ‌هایی با آزردگی فزاینده برمی‌گرداند.

defmodule AnnoyingPassengerAutoresponder do
  use GenServer
  # Client API

  def start_link(init_arg) do
    GenServer.start_link(__MODULE__, init_arg)
  end

  def are_we_there_yet?(pid) do
    GenServer.call(pid, :are_we_there_yet?)
  end

  # Server callbacks

  @impl GenServer
  def init(_init_arg) do
    # the initial count of questions asked is always 0
    state = 0
    {:ok, state}
  end

  @impl GenServer
  def handle_call(:are_we_there_yet?, _from, state) do
    reply =
      cond do
        state <= 3 -> "No."
        state <= 10 -> "I told you #{state} times already. No."
        true -> "..."
      end

    # increase the count of questions asked
    new_state = state + 1
    # reply to the caller
    {:reply, reply, new_state}
  end
end

کال‌بک‌ها

init/1

یک سرور را می‌توان با فراخوانی GenServer.start/3 یا GenServer.start_link/3 راه‌اندازی کرد. تفاوت این دو تابع را در مفهوم پیوندها یاد گرفتیم.

این دو تابع:

• یک ماژول را که «رفتار» GenServer را پیاده‌سازی می‌کند به عنوان آرگومان اول می‌پذیرند.
• هر چیزی را به عنوان آرگومان دوم به اسم init_arg می‌پذیرند. همان‌طور که از اسمش پیداست، این آرگومان به کال‌بک init/1 فرستاده می‌شود.
• آرگومان سوم اختیاری را با گزینه‌های پیشرفته‌ی اجرای فرایند می‌پذیرند که فعلاً به آن نمی‌پردازیم.

راه‌اندازی یک سرور با فراخوانی GenServer.start/3 یا GenServer.start_link/3، کال‌بک init/1 را به‌صورت مسدودکننده فراخوانی می‌کند. مقدار بازگشتی init/1 تعیین می‌کند که آیا سرور با موفقیت راه‌اندازی می‌شود یا نه.

کال‌بک init/1 معمولاً یکی از این مقادیر را برمی‌گرداند:

• {:ok, state}. سرور حلقه‌ی دریافت خود را با state به عنوان وضعیت اولیه‌اش آغاز می‌کند. state می‌تواند از هر نوعی باشد.
• {:stop, reason}. reason می‌تواند از هر نوعی باشد. سرور حلقه‌ی دریافت خود را آغاز نمی‌کند. فرایند با دلیل داده‌شده خارج می‌شود.

امکانات پیشرفته‌ی دیگری هم هست که فعلاً به آن‌ها نمی‌پردازیم.

اگر حلقه‌ی دریافت سرور آغاز شود، توابع GenServer.start/3 و GenServer.start_link/3 یک تاپل {:ok, pid} برمی‌گردانند. در غیر این صورت {:error, reason} را برمی‌گردانند.

handle_call/3

پیامی را که به پاسخ نیاز دارد می‌توان با GenServer.call/2 به یک فرایند سرور فرستاد. این تابع pid یک فرایند سرور در حال اجرا را به عنوان آرگومان اول و پیام را به عنوان آرگومان دوم انتظار دارد. پیام می‌تواند از هر نوعی باشد.

کال‌بک handle_call/3 مسئول رسیدگی به پیام‌های همگام و پاسخ دادن به آن‌هاست. سه آرگومان دریافت می‌کند:

1. message: مقداری که به عنوان آرگومان دوم به GenServer.call/2 فرستاده شده است.
2. from: pid فرایندی که GenServer.call/2 را فراخوانی کرده است. در بیشتر موارد می‌توان این آرگومان را نادیده گرفت.
3. state: وضعیت فعلی سرور. یادتان باشد که مقدار اولیه‌ی آن در کال‌بک init/1 تعیین شده بود.

کال‌بک handle_call/3 معمولاً یک تاپل ۳تایی به شکل {:reply, reply, state} برمی‌گرداند. یعنی عنصر دوم تاپل، یعنی reply که می‌تواند از هر نوعی باشد، به فراخواننده بازگردانده می‌شود. عنصر سوم تاپل، یعنی state، وضعیت جدید سرور پس از رسیدگی به این پیام است.

امکانات پیشرفته‌ی دیگری هم هست که فعلاً به آن‌ها نمی‌پردازیم.

handle_cast/2

پیامی را که به پاسخ نیاز ندارد می‌توان با GenServer.cast/2 به یک فرایند سرور فرستاد. آرگومان‌هایش با آرگومان‌های GenServer.call/2 یکسان است.

کال‌بک handle_cast/2 مسئول رسیدگی به این پیام‌هاست. دو آرگومان دریافت می‌کند، message و state، که همان آرگومان‌های کال‌بک handle_call/3 هستند (به‌جز from).

کال‌بک handle_cast/2 معمولاً یک تاپل ۲تایی به شکل {:noreply, state} برمی‌گرداند.

امکانات پیشرفته‌ی دیگری هم هست که فعلاً به آن‌ها نمی‌پردازیم.

از call استفاده کنم یا cast؟

تقریباً همیشه از call استفاده کنید، حتی اگر کد کلاینت شما به پاسخ سرور نیازی نداشته باشد.

استفاده از call منتظر پاسخ می‌ماند، که به عنوان مکانیزمی برای فشار برگشتی عمل می‌کند (تا مانع فرستادن پیام‌های بیش از حد از سوی کلاینت‌ها به‌طور همزمان شود). دریافت پاسخ از سرور هم تنها راه اطمینان از این است که سرور پیام کلاینت را دریافت و پردازش کرده است.

handle_info/2

پیام‌ها می‌توانند به روش‌هایی جز فراخوانی GenServer.call/2 یا GenServer.cast/2 هم به صندوق پیام سرور برسند، مثلاً با فراخوانی تابع ساده‌ی send/2.

برای رسیدگی به چنین پیام‌هایی، از کال‌بک handle_info/2 استفاده کنید. این کال‌بک دقیقاً به همان روش handle_cast/2 کار می‌کند.

«رفتار» GenServer یک پیاده‌سازی جامع از handle_info/2 فراهم می‌کند که خطاهای مربوط به پیام‌های غیرمنتظره را ثبت می‌کند. اگر آن پیاده‌سازی پیش‌فرض را بازنویسی می‌کنید، حتماً پیاده‌سازی جامع خودتان را هم بگنجانید. اگر فراموش کنید، سرور در صورت دریافت یک پیام غیرمنتظره از کار می‌افتد.

مهلت‌ها

مقدار بازگشتی هر یک از چهار کال‌بک توصیف‌شده در بالا را می‌توان با یک عنصر دیگر تاپل، یعنی یک «مهلت»، گسترش داد. برای مثال، به‌جای برگرداندن {:ok, state} از init/1، {:ok, state, timeout} را برگردانید.

از مهلت می‌توان برای تشخیص نبود پیام در صندوق پیام در یک بازه‌ی زمانی مشخص استفاده کرد. اگر سرور از یکی از کال‌بک‌هایش یک مهلت برگرداند و تعداد میلی‌ثانیه‌ی مشخص‌شده بدون رسیدن هیچ پیامی بگذرد، handle_info/2 با :timeout به عنوان آرگومان اول فراخوانی می‌شود.