<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>systems-programming on toorun.dev</title><link>https://toorun.dev/tags/systems-programming/</link><description>Recent content in systems-programming on toorun.dev</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Sat, 25 Jul 2026 11:00:00 +0000</lastBuildDate><atom:link href="https://toorun.dev/tags/systems-programming/index.xml" rel="self" type="application/rss+xml"/><item><title>Linux Signals: Custom Ctrl+C Handler (SIGINT, SIGUSR1, SIGALRM)</title><link>https://toorun.dev/posts/linux-signals-ctrl-c-handler-sigint-sigalrm-sigusr1/</link><pubDate>Sat, 25 Jul 2026 11:00:00 +0000</pubDate><guid>https://toorun.dev/posts/linux-signals-ctrl-c-handler-sigint-sigalrm-sigusr1/</guid><description>Linux Signals: Custom Ctrl+C Handler (Short Practical Guide) In Linux/embedded Linux, signals are useful for lightweight control events. Typical use: stop, reload, notify, timeout.
This example shows:
Custom Ctrl+C (SIGINT) behavior Sending SIGUSR1 to another process Using SIGALRM as a timeout Full short example #include &amp;lt;signal.h&amp;gt; #include &amp;lt;stdio.h&amp;gt; #include &amp;lt;stdlib.h&amp;gt; #include &amp;lt;unistd.h&amp;gt; #define W(msg) write(STDOUT_FILENO, msg, sizeof(msg) - 1) static volatile sig_atomic_t running = 1; static volatile sig_atomic_t got_usr1 = 0; static volatile sig_atomic_t child_pid = -1; static void on_sigint(int sig) { (void)sig; W(&amp;#34;\nSIGINT: Ctrl+C caught.</description></item><item><title>Linux IPC in Embedded Systems: Short Practical Guide</title><link>https://toorun.dev/posts/linux-ipc-embedded-linux-practical-guide/</link><pubDate>Sat, 25 Jul 2026 10:00:00 +0000</pubDate><guid>https://toorun.dev/posts/linux-ipc-embedded-linux-practical-guide/</guid><description>Linux IPC in Embedded Systems (Short Practical Guide) IPC (Inter-Process Communication) lets processes exchange data and signals. In embedded Linux, IPC choice affects latency, memory use, complexity, and reliability.
Quick selection Stream logs or simple producer-&amp;gt;consumer: pipe / FIFO Request/response between local services: Unix domain socket Structured async messages with priorities: POSIX message queue High-throughput low-latency data path: shared memory + semaphore/mutex Simple notifications/events: signal or eventfd 1) Pipe/FIFO Best for Simple one-way byte stream Shell-like pipelines or parent-child communication Pros Very simple API Low overhead Cons Byte stream only (no message boundaries) Multi-writer design becomes messy // parent writes, child reads int fd[2]; pipe(fd); if (fork() == 0) { close(fd[1]); char buf[64] = {0}; read(fd[0], buf, sizeof(buf)); printf(&amp;#34;child got: %s\n&amp;#34;, buf); _exit(0); } close(fd[0]); write(fd[1], &amp;#34;hello&amp;#34;, 5); 2) Unix Domain Socket (AF_UNIX) Best for Local client/server daemons Need bidirectional communication and framing Pros Faster than TCP loopback for local IPC Supports stream or datagram modes Can pass file descriptors (SCM_RIGHTS) Cons More setup than pipes Protocol framing is your responsibility // server side (minimal) int s = socket(AF_UNIX, SOCK_STREAM, 0); struct sockaddr_un addr = {.</description></item></channel></rss>