Erlang OTP: Distributed & Fault-Tolerant Systems Programming · Ders

Denetleyici Köprüleri ve Karma Süreç Hiyerarşileri

Hata toleransını koruyarak supervisor_bridge kullanımıyla OTP dışı süreçleri ve harici alt sistemleri denetim ağacınıza tümleştirin.

Denetleyici Köprüleri ve Karma Süreç Hiyerarşileri, CoddyKit'te ücretsiz bir Erlang OTP: Distributed & Fault-Tolerant Systems Programming dersidir. Bu, 4 dersinin 4. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, Erlang OTP: Distributed & Fault-Tolerant Systems Programming öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. Erlang OTP: Distributed & Fault-Tolerant Systems Programming kursu toplamda 4 dersten oluşur.

Bu dersin bazı bölümleri henüz çevrilmemiş olup İngilizce olarak gösterilmektedir.

Why a Supervisor Bridge?

Not every process you depend on is a clean OTP gen_server. Sometimes you must supervise a plain Erlang process, a port, or a third-party subsystem. The supervisor_bridge behaviour lets such a process appear as a normal child in a supervision tree.

The Problem It Solves

A standard supervisor only knows how to start, stop and restart OTP-compliant children. A raw process started with spawn_link does not respond to OTP shutdown protocols. The bridge translates between the two worlds.

Behaviour Callbacks

A supervisor_bridge module implements two callbacks:

init/1 starts the real subsystem and returns its pid
terminate/2 cleanly shuts the subsystem down

Skeleton Module

The bridge is started like a supervisor but behaves like a worker to its parent.

-module(legacy_bridge).
-behaviour(supervisor_bridge).
-export([start_link/0, init/1, terminate/2]).

start_link() ->
    supervisor_bridge:start_link({local, ?MODULE}, ?MODULE, []).

Implementing init/1

init/1 must start and link the external process, then return {ok, Pid, State}. If start fails, return {error, Reason}.

init([]) ->
    case legacy_server:start() of
        {ok, Pid} -> {ok, Pid, Pid};
        Error -> Error
    end.

Implementing terminate/2

When the bridge is asked to shut down, it calls terminate/2 so you can stop the subsystem gracefully.

terminate(_Reason, Pid) ->
    legacy_server:stop(Pid),
    ok.

Placing the Bridge in a Tree

To its parent supervisor, the bridge is just another child spec with type => worker.

ChildSpec = #{id => legacy,
              start => {legacy_bridge, start_link, []},
              restart => permanent,
              type => worker}.

Failure Propagation

Because the bridge links to the external process, a crash there exits the bridge, which the parent supervisor sees as a normal worker crash and restarts according to its strategy.

Mixed Hierarchies

A real system mixes gen_server workers, sub-supervisors, and bridges. The bridge lets legacy or foreign code participate without weakening the OTP guarantees of the rest of the tree.

When NOT to Use a Bridge

If you can wrap the subsystem in a proper gen_server, prefer that — it gives you full OTP introspection. Reserve the bridge for code you cannot rewrite or that has its own process lifecycle.

Debugging Bridged Subsystems

Because the inner process is not OTP, tools like sys:get_state/1 will not reach it. Add logging inside the subsystem and rely on the bridge state to track the inner pid.

Quick Check

Test your understanding of supervisor bridges.

Recap

You learned to integrate foreign processes into supervision trees:

supervisor_bridge wraps non-OTP subsystems
init/1 starts and links the subsystem; terminate/2 stops it
It appears as a worker child to its parent supervisor
Crashes propagate so normal restart strategies apply
Prefer a real gen_server when you control the code

Sıkça Sorulan Sorular

“Denetleyici Köprüleri ve Karma Süreç Hiyerarşileri” dersi ücretsiz mi?

Evet — “Denetleyici Köprüleri ve Karma Süreç Hiyerarşileri” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve Erlang OTP: Distributed & Fault-Tolerant Systems Programming kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. Erlang OTP: Distributed & Fault-Tolerant Systems Programming kursu toplamda 4 dersten oluşur.

“Denetleyici Köprüleri ve Karma Süreç Hiyerarşileri” dersinde ne öğreneceğim?

Hata toleransını koruyarak supervisor_bridge kullanımıyla OTP dışı süreçleri ve harici alt sistemleri denetim ağacınıza tümleştirin. Erlang OTP: Distributed & Fault-Tolerant Systems Programming ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

Erlang OTP: Distributed & Fault-Tolerant Systems Programming öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te Erlang OTP: Distributed & Fault-Tolerant Systems Programming, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 4. dersidir.

“Denetleyici Köprüleri ve Karma Süreç Hiyerarşileri” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu Erlang OTP: Distributed & Fault-Tolerant Systems Programming dersinde kod yazıp çalıştırabilir miyim?

Evet. Her Erlang OTP: Distributed & Fault-Tolerant Systems Programming dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

Karmaşık Gözetim Ağaçları
Dinamik Süreç Yönetimi
İleri Düzey Yeniden Başlatma Stratejileri
Denetleyici Köprüleri ve Karma Süreç Hiyerarşileri

← Erlang OTP: Distributed & Fault-Tolerant Systems Programming Sayfasına Dön