<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Rekayasa Perangkat Lunak on Nalar</title>
    <link>https://nalar.dev/id/software-engineering/</link>
    <description>Recent content in Rekayasa Perangkat Lunak on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Thu, 17 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/software-engineering/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>EPOLLET Melaporkan Transisi Readiness, Bukan Pengosongan Buffer</title>
      <link>https://nalar.dev/id/epollet-melaporkan-transisi-readiness-bukan-pengosongan-buffer/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/epollet-melaporkan-transisi-readiness-bukan-pengosongan-buffer/</guid>
      <description>&lt;p&gt;Dengan &lt;code&gt;EPOLLET&lt;/code&gt;, sebuah file descriptor dapat tetap memiliki data yang belum dibaca setelah event readiness-nya sudah dikonsumsi. Pemanggilan &lt;code&gt;epoll_wait()&lt;/code&gt; berikutnya tidak wajib melaporkan descriptor itu lagi hanya karena state readable sebelumnya masih bertahan.&lt;/p&gt;&#xA;&lt;p&gt;Perilaku ini merupakan batas utama edge-triggered epoll: notifikasi mengikuti perubahan readiness, sedangkan objek I/O di bawahnya mempertahankan state sendiri secara terpisah.&lt;/p&gt;&#xA;&lt;h2 id=&#34;readiness-dan-pengiriman-event-merupakan-state-terpisah&#34;&gt;Readiness dan pengiriman event merupakan state terpisah&lt;/h2&gt;&#xA;&lt;p&gt;Sebuah epoll instance memiliki interest list dan ready list. Registrasi melalui &lt;code&gt;epoll_ctl()&lt;/code&gt; menentukan open file description yang dipantau dan kelas event yang relevan. &lt;code&gt;epoll_wait()&lt;/code&gt; mengembalikan entry yang sudah mencapai ready list.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Event Linux inotify Merupakan Aliran Perubahan yang Dapat Kehilangan Data</title>
      <link>https://nalar.dev/id/event-linux-inotify-merupakan-aliran-perubahan-yang-dapat-kehilangan-data/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/event-linux-inotify-merupakan-aliran-perubahan-yang-dapat-kehilangan-data/</guid>
      <description>&lt;p&gt;File descriptor inotify memaparkan aktivitas filesystem sebagai antrean terurut berisi record event, tetapi antrean tersebut bukan riwayat otoritatif atas state namespace. Event identik yang belum dibaca dapat digabungkan, kapasitas antrean terbatas, dan overflow secara eksplisit berarti sejumlah event telah hilang. Proses yang memperlakukan aliran ini sebagai transaction log lengkap dapat mempertahankan state yang tidak lagi sesuai dengan filesystem.&lt;/p&gt;&#xA;&lt;p&gt;Model yang lebih tepat adalah notifikasi perubahan dengan kewajiban pemulihan. Event dapat menjaga cache tetap mutakhir secara inkremental selama alirannya utuh; kondisi tertentu memutus riwayat inkremental tersebut dan menuntut rekonsiliasi terhadap state filesystem.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Linux eventfd Membuat Status Counter Dapat Dipantau</title>
      <link>https://nalar.dev/id/linux-eventfd-membuat-status-counter-dapat-dipantau/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/linux-eventfd-membuat-status-counter-dapat-dipantau/</guid>
      <description>&lt;p&gt;Linux eventfd dapat menggabungkan banyak notifikasi ke dalam satu counter yang dikelola kernel sambil tetap dapat digunakan dengan &lt;code&gt;poll()&lt;/code&gt;, &lt;code&gt;select()&lt;/code&gt;, dan &lt;code&gt;epoll&lt;/code&gt;. Writer menambahkan nilai unsigned 64-bit ke counter; readiness menyatakan apakah status tersebut dapat dikonsumsi. Interface ini membawa status aritmetika, bukan byte stream atau antrean pesan individual.&lt;/p&gt;&#xA;&lt;p&gt;Perbedaan tersebut penting pada batas proses dan thread. Sebuah wakeup menyatakan bahwa counter bukan nol. Wakeup itu tidak mempertahankan jumlah operasi write, identitas writer, atau urutan di antara sumber notifikasi yang terpisah.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Linux memfd Seals Mengubah Byte Mutable Menjadi Kontrak yang Ditegakkan Kernel</title>
      <link>https://nalar.dev/id/linux-memfd-seals-mengubah-byte-mutable-menjadi-kontrak-kernel/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/linux-memfd-seals-mengubah-byte-mutable-menjadi-kontrak-kernel/</guid>
      <description>&lt;p&gt;Sebuah memfd dapat dimulai sebagai anonymous file yang writable lalu menolak kelas mutasi tertentu melalui seal yang ditegakkan kernel. Transisi ini melekat pada inode, bukan pada satu descriptor, sehingga proses tidak dapat mempertahankan duplicate descriptor tanpa pembatasan untuk melewati seal yang dipasang melalui referensi lain.&lt;/p&gt;&#xA;&lt;p&gt;Sifat tersebut berbeda dari memberikan descriptor dengan mode akses yang lebih sempit kepada komponen lain. Mode akses descriptor membatasi satu open file description. Seal mengubah operasi yang diizinkan kernel terhadap file itu sendiri, termasuk operasi melalui descriptor lain yang merujuk inode yang sama.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Linux openat2 Membuat Batas Resolusi Path Menjadi Atomik</title>
      <link>https://nalar.dev/id/linux-openat2-membuat-batas-resolusi-path-menjadi-atomik/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/linux-openat2-membuat-batas-resolusi-path-menjadi-atomik/</guid>
      <description>&lt;p&gt;Sebuah pathname dapat menunjuk ke objek yang berbeda ketika lookup kedua dilakukan. Di Linux, &lt;code&gt;openat2()&lt;/code&gt; menangani batas ini dengan menempelkan aturan resolusi pada operasi kernel yang sama dengan operasi yang menelusuri pathname dan membuka objek hasilnya. Kebijakan dievaluasi selama lookup berlangsung, bukan disimpulkan dari pathname yang diperiksa sebelum atau sesudah file dibuka.&lt;/p&gt;&#xA;&lt;p&gt;Perbedaan ini penting ketika proses menerima komponen path dari sumber yang kurang tepercaya tetapi ingin memastikan resolusi tetap berada di dalam direktori tertentu, menolak symbolic link, mencegah perpindahan mount, atau mewajibkan lookup yang hanya memakai cache. Objek yang penting bukan hanya string input, melainkan hasil resolusi string tersebut terhadap namespace aktif yang isi direktori, link, dan mount-nya dapat berubah secara bersamaan.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Linux signalfd Mengubah Sinyal Pending Menjadi Status Readable</title>
      <link>https://nalar.dev/id/linux-signalfd-mengubah-sinyal-pending-menjadi-status-readable/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/linux-signalfd-mengubah-sinyal-pending-menjadi-status-readable/</guid>
      <description>&lt;p&gt;Proses Linux dapat memblokir sinyal tertentu lalu menerimanya dengan membaca file descriptor alih-alih menjalankan handler asinkron. &lt;code&gt;signalfd()&lt;/code&gt; membuat sinyal pending tersebut terlihat melalui antarmuka readiness yang sama dengan socket, pipe, dan descriptor lain, termasuk &lt;code&gt;poll()&lt;/code&gt; dan &lt;code&gt;epoll&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Konversi ini bukan pengganti signal masking. Descriptor memiliki himpunan sinyal sendiri, sementara setiap thread tetap memiliki signal mask yang mengendalikan delivery biasa. Desain yang konsisten bergantung pada keselarasan kedua status tersebut.&lt;/p&gt;&#xA;&lt;h2 id=&#34;descriptor-mengamati-sinyal-pending-dari-himpunan-tertentu&#34;&gt;Descriptor mengamati sinyal pending dari himpunan tertentu&lt;/h2&gt;&#xA;&lt;p&gt;signalfd baru dibuat dengan sebuah himpunan sinyal:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Linux splice Menjadikan Pipe sebagai Batas Transfer Data Kernel</title>
      <link>https://nalar.dev/id/linux-splice-menjadikan-pipe-sebagai-batas-transfer-data-kernel/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/linux-splice-menjadikan-pipe-sebagai-batas-transfer-data-kernel/</guid>
      <description>&lt;p&gt;&lt;code&gt;splice()&lt;/code&gt; dapat memindahkan byte antara dua file descriptor tanpa terlebih dahulu menyalin payload ke buffer userspace, tetapi antarmukanya mengharuskan setidaknya satu endpoint berupa pipe. Syarat ini menjadikan pipe lebih dari sekadar transport perantara. Pipe adalah batas buffer yang terlihat oleh kernel, tempat semantik offset, blocking, kapasitas, dan partial progress operasi tersebut dibentuk.&lt;/p&gt;&#xA;&lt;p&gt;Hal ini berbeda dari &lt;code&gt;read()&lt;/code&gt; yang diikuti &lt;code&gt;write()&lt;/code&gt;. Pada urutan tersebut, userspace memiliki array byte perantara dan dapat memeriksa atau mengubahnya. Dengan &lt;code&gt;splice()&lt;/code&gt;, payload dapat tetap berada di storage yang dikelola kernel sementara proses mengoordinasikan perpindahan antar-endpoint.&lt;/p&gt;</description>
    </item>
    <item>
      <title>pidfd Linux Mengubah Identitas Proses Menjadi Handle yang Dapat Dipantau</title>
      <link>https://nalar.dev/id/pidfd-linux-mengubah-identitas-proses-menjadi-handle-yang-dapat-dipantau/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/pidfd-linux-mengubah-identitas-proses-menjadi-handle-yang-dapat-dipantau/</guid>
      <description>&lt;p&gt;PID Linux adalah angka dari namespace yang dapat digunakan ulang. pidfd berbeda: ia adalah file descriptor yang merujuk ke proses tertentu. Perbedaan itu mengubah pengelolaan proses dari lookup berulang berdasarkan nama numerik menjadi operasi terhadap handle yang dipertahankan kernel dan identitasnya tidak diam-diam berpindah ketika PID didaur ulang.&lt;/p&gt;&#xA;&lt;p&gt;Perbedaannya paling terlihat pada supervisor, launcher, sandbox, dan service manager yang mempertahankan referensi proses melintasi pekerjaan asynchronous. PID numerik dapat tetap valid secara sintaksis setelah proses asli keluar, tetapi kemudian mengidentifikasi proses lain. pidfd menjaga referensi tetap terikat pada objek proses asli dan juga dapat berpartisipasi dalam event loop berbasis descriptor.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Read pada Linux timerfd Melaporkan Akumulasi Expiration</title>
      <link>https://nalar.dev/id/read-linux-timerfd-melaporkan-akumulasi-expiration/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/read-linux-timerfd-melaporkan-akumulasi-expiration/</guid>
      <description>&lt;p&gt;timerfd periodik pada Linux dapat mengalami beberapa expiration sebelum event loop membacanya. &lt;code&gt;read()&lt;/code&gt; berikutnya yang berhasil tidak mengembalikan satu record untuk setiap wakeup. Operasi itu mengembalikan satu &lt;code&gt;uint64_t&lt;/code&gt; dalam byte order host yang berisi jumlah expiration yang terakumulasi sejak timer terakhir di-arm atau sejak read berhasil sebelumnya.&lt;/p&gt;&#xA;&lt;p&gt;Count tersebut menjadikan readiness timerfd sebagai notifikasi bahwa status timer dapat dikonsumsi, bukan pemetaan satu-ke-satu antara wakeup scheduler dan periode timer.&lt;/p&gt;&#xA;&lt;h2 id=&#34;read-mengonsumsi-count-expiration-yang-terakumulasi&#34;&gt;Read mengonsumsi count expiration yang terakumulasi&lt;/h2&gt;&#xA;&lt;p&gt;timerfd yang dibuat dengan &lt;code&gt;timerfd_create()&lt;/code&gt; merepresentasikan satu timer kernel melalui file descriptor. &lt;code&gt;timerfd_settime()&lt;/code&gt; menetapkan expiration awal pada &lt;code&gt;it_value&lt;/code&gt; dan, untuk timer periodik, &lt;code&gt;it_interval&lt;/code&gt; yang bukan nol.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Shared Ring io_uring Menjadikan Memory Ordering Bagian dari ABI</title>
      <link>https://nalar.dev/id/shared-ring-io-uring-menjadikan-memory-ordering-bagian-dari-abi/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/shared-ring-io-uring-menjadikan-memory-ordering-bagian-dari-abi/</guid>
      <description>&lt;p&gt;Queue &lt;code&gt;io_uring&lt;/code&gt; adalah shared memory yang diubah oleh dua domain eksekusi independen. User space menyiapkan submission entry dan memajukan metadata queue; kernel mengonsumsi submission tersebut lalu memublikasikan completion entry. Layout ring menghilangkan satu batas copy, tetapi pada saat yang sama membuat visibilitas memori menjadi bagian dari kontrak interface.&lt;/p&gt;&#xA;&lt;p&gt;Assignment biasa pada level source ke tail queue tidak cukup sebagai model publikasi yang portabel. Data entry harus terlihat lebih dulu sebelum nilai tail yang membuat entry tersebut boleh dikonsumsi. Di sisi completion, user space harus mengamati publikasi completion dari kernel sebelum membaca field di completion tersebut. Relasi ordering ini adalah bagian dari correctness, bukan sekadar detail optimasi.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
