Deferred Publishing

Kenapa halaman ini penting

Halaman ini menjelaskan bagaimana Deferred Publishing masuk ke model eksekusi ZeroKernel yang lebih besar, masalah apa yang sebenarnya diselesaikan, dan trade-off apa yang benar-benar Anda bayar saat fitur ini dipakai di firmware produksi. Tujuannya bukan melihat Deferred Publishing sebagai satu API terpisah, tetapi memahami posisinya di dalam bounded scheduling, disiplin queue, visibilitas fault, dan pemilihan profile.

Baca topik ini sebagai kontrak operasional. Mulai dari jalur paling kecil yang benar-benar jalan, pasang dulu di profile lean, lalu baru naik ke routing, diagnostics, atau state transport yang lebih kaya setelah Anda bisa membuktikan hasil timing-nya tetap layak dibanding tambahan flash dan RAM. Pola pikir ini yang menjaga ZeroKernel tetap berguna di board kecil dan tidak berubah jadi abstraksi yang gemuk.

Pola paling aman selalu sama: tentukan batas runtime-nya, jaga hot path tetap pendek, ukur efeknya dengan compare script, lalu baru naikkan kompleksitas. Contoh di bawah bukan pemanis; itu adalah pola minimum yang bisa Anda ambil ke firmware nyata saat Anda butuh integrasi yang rapi, bukan loop manual yang sulit dipertahankan.

Tiga pola yang langsung bisa dipakai

    ZeroKernel.begin(boardMillis);
ZeroKernel.addTask("Fast", fastTask, 10, 0, true);
ZeroKernel.tick();
  

    const auto key = ZeroKernel.makeTopicKey("telemetry.sample");
ZeroKernel.publishDeferredFast(key, sampleValue);
ZeroKernel.flushEvents();
  

    const auto stats = ZeroKernel.getStats();
const auto timing = ZeroKernel.getTimingReport();
Serial.println(timing.maxTickMs);
  

Apa yang perlu Anda cek saat memakainya

• Validasi timing lebih dulu, baru bentuk API. API yang terlihat rapi bukan kemenangan kalau fast miss justru naik.
• Pilih profile paling kecil yang masih cocok, lalu aktifkan modul opsional hanya saat payoff terukurnya benar-benar jelas.
• Jaga callback dan langkah transport tetap bounded supaya watchdog, panic flow, dan batas queue tetap punya arti.

Kesalahan umum yang membuat hasil jadi menyesatkan

• Jangan menyalin pola demo ke firmware produksi tanpa mengukurnya di board dan profile build yang benar-benar akan dipakai.
• Jangan membaca angka sukses tanpa membaca queue depth, timing, dan label workload di sampingnya.
• Jangan menyalakan diagnostics atau kompatibilitas berat di target lean hanya karena default-nya terasa nyaman.

Urutan kerja yang disarankan

Kenapa deferred routing ada

Deferred publishing ada untuk melindungi hot path. Task produsen yang cepat tidak seharusnya membayar seluruh biaya pekerjaan konsumen, terutama jika konsumen itu akan memformat data, menyentuh state transport, atau memicu langkah follow-up yang lebih lambat.

Dengan menaruh publikasi ke queue yang bounded, task produsen bisa tetap pendek sementara runtime menguras pekerjaan lanjutan secara bertahap. Inilah salah satu cara paling praktis ZeroKernel menjaga firmware tetap responsif tanpa pura-pura bahwa pekerjaan itu gratis.

    const auto telemetryKey = ZeroKernel.makeTopicKey("telemetry.sample");
ZeroKernel.publishDeferredFast(telemetryKey, 42);
  

Kapan deferred adalah pilihan yang benar

• Saat task sampling cepat tidak boleh langsung memicu formatting atau transport.
• Saat Anda ingin queue depth menjadi terlihat dan terukur.
• Saat konsumen masih bisa menoleransi delay satu putaran scheduler, tetapi produsen tidak boleh blocking.

Deferred routing bukan sekadar “versi lebih canggih” dari direct publish. Fungsinya adalah isolasi. Pakai saat isolasi itu memang memberi nilai runtime yang nyata.

Tiga pola deferred yang paling berguna

    const auto sampleKey = ZeroKernel.makeTopicKey("sample.fast");
ZeroKernel.publishDeferredFast(sampleKey, sampleValue);
  

Ini pola produsen-konsumen klasik: task cepat mengirim, lalu langsung selesai.

    const auto alarmKey = ZeroKernel.makeTopicKey("alarm.edge");
if (thresholdCrossed) {
  ZeroKernel.publishDeferredFast(alarmKey, 1);
}
  

Pakai ini saat event penting, tetapi responsnya tetap harus dibudget dan tetap terlihat.

    ZeroKernel.publishDeferredFast(key, payload);
ZeroKernel.flushEvents();
  

Pola flush eksplisit ini berguna di konteks yang terkendali saat Anda ingin memaksa queue bergerak di titik yang sudah diketahui, tetapi tetap melalui mekanisme event yang bounded.

Failure mode dan tekanan queue

Jika produsen publish lebih cepat daripada drain budget bisa mengonsumsi, queue akan tumbuh, coalescing mulai berpengaruh, dan runtime akhirnya akan menunjukkan tekanan itu lewat metrik queue dan counter drop. Ini bukan bug queue; ini sinyal bahwa laju produksi dan budget konsumsi sudah tidak seimbang.

Perbaikannya biasanya salah satu dari tiga hal: turunkan cadence produsen, naikkan drain budget dengan sengaja, atau pecah konsumen yang terlalu berat agar satu item queue tidak membayar terlalu banyak pekerjaan.

FAQ deferred publish