# IPC Published articles for IPC. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Mir/Wayland-Powered Miracle-WM 0.11 Released With New Overview Mode, Window Urgency DevFeed: [Mir/Wayland-Powered Miracle-WM 0.11 Released With New Overview Mode, Window Urgency]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-17T00:58:42Z Content type: release Language: en Sources: [Phoronix]() Topics: [Wayland](), [Library](), [canonical]() Tags: [commands](), [data](), [desktop-linux](), [events](), [github](), [image](), [input](), [ipc](), [library](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open-source-graphics](), [overview](), [phoronix](), [phoronix-test-suite](), [plugins](), [release](), [ubuntu-benchmarks](), [ubuntu-hardware](), [update](), [wayland](), [window](), [windows]() ### AI overview Miracle-WM 0.11, a Wayland compositor built on the Mir library, adds an overview mode, window urgency support, plugin IPC events and commands, and support for newer Mir protocols. The release is built on Mir 2.29. ### Source excerpt Canonical engineer Matthew Kosarek rolled out Miracle-WM 0.11 today as an end-of-summer update to this Wayland compositor built atop the Mir library... ## What We Learned Building a Rust Runtime for TypeScript DevFeed: [What We Learned Building a Rust Runtime for TypeScript]() Original publisher: [Read original article]() Author: Ivan Cernja Published: 2026-04-08T00:00:00Z Content type: article Language: en Sources: [Encore Updates]() Topics: [Rust](), [TypeScript](), [Tokio](), [tracing](), [Pingora]() Tags: [building](), [ipc](), [latency](), [performance](), [pingora](), [rust](), [tokio](), [tracing](), [typescript]() ### AI overview Encore describes building a Rust runtime for TypeScript applications. The runtime moves infrastructure work such as HTTP handling, database connectivity, pub/sub, tracing, metrics, storage, caching, and API gateway functions into Rust running on Tokio, while TypeScript handles application business logic. The article also explains why an IPC-based Go sidecar prototype introduced measurable latency overhead. ### Source excerpt 67,000 lines of Rust, two years, and the non-obvious problems of making Node.js and Rust work together in the same process. ## Gentoo GNU/Hurd Released with QEMU Boot Image Build Scripts DevFeed: [Gentoo GNU/Hurd Released with QEMU Boot Image Build Scripts]() Original publisher: [Read original article]() Published: 2026-04-01T00:00:00Z Content type: release Language: en Sources: [GNU Hurd]() Topics: [GNU/Hurd](), [Unix](), [Kernel](), [qemu]() Tags: [2026](), [announcement](), [distributed](), [gnu-hurd](), [ipc](), [linux](), [qemu](), [replacement](), [unix]() ### AI overview Gentoo GNU/Hurd has been released. The announcement points to scripts for building a working image that can boot in QEMU and describes GNU Hurd as a replacement for the Unix kernel. ### Source excerpt Gentoo GNU/Hurd released! Details. " The year is 2026 and Gentoo is perhaps ready for an advanced kernel: the GNU Hurd. [...] Scripts to build a working image that can be booted in QEMU can be found at https://codeberg.org/thesamesam/gentoo-hurd (will move that to Gentoo infra). " Read the announcement email. The GNU Hurd is the GNU project's replacement for the Unix kernel. It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux). More detailed. GNU Mach is the microkernel upon which a GNU Hurd system is based. It provides an Inter Process Communication (IPC) mechanism that the Hurd uses to define interfaces for implementing in a distributed multi-server fashion the services a traditional operating system kernel provides. More detailed. ## Introducing multi-language dynamic plugins for Redpanda Connect DevFeed: [Introducing multi-language dynamic plugins for Redpanda Connect]() Original publisher: [Read original article]() Author: James Kinley Published: 2025-06-17T00:00:00Z Content type: release Language: en Sources: [Redpanda]() Topics: [gRPC](), [SDKs](), [Go Language](), [Python](), [Processes](), [streaming-data-processing](), [Unix]() Tags: [ai-ml-capabilities-in-streaming-data](), [architecture](), [configuration](), [creating-plugins-in-golang-and-python](), [dynamic-vs-compiled-plugins](), [framework](), [go](), [grpc-plugin-system](), [integration](), [interfaces](), [ipc](), [language-agnostic-plugin-system](), [multi-language-plugin-development](), [pipelines](), [plugin-development](), [plugins](), [process](), [processes](), [product](), [protocol](), [python](), [python-sdk-for-streaming-data](), [redpanda-connect](), [redpanda-connect-dynamic-plugins](), [redpanda-streaming-infrastructure](), [runtime-loaded-plugins-grpc](), [sdk](), [sdks](), [stream-processing](), [streaming-data-pipeline-plugins]() ### AI overview Redpanda Connect introduces Apache 2.0-licensed dynamic plugins in Beta with version 4.56.0. Plugins can be loaded at runtime as external executables that communicate with the main process through gRPC over Unix sockets, enabling plugin development in Go and Python. Official SDKs support both languages, while native Go plugins remain the preferred option for performance-critical workloads. ### Source excerpt Redpanda Connect dynamic plugins framework allows you to create and load plugins at runtime, opening up a world of new integration possibilities beyond Go. ## Snapshots for IPC Fuzzing DevFeed: [Snapshots for IPC Fuzzing]() Original publisher: [Read original article]() Author: Christian Holler Published: 2024-06-27T16:18:49Z Content type: article Language: en Sources: [Mozilla Hacks - the Web developer blog]() Topics: [Fuzzing/Fuzz testing](), [Firefox](), [out-of-process](), [Security](), [Vulnerabilities](), [Testing]() Tags: [featured-article](), [firefox](), [fuzzing](), [ipc](), [memory-safety](), [mozilla](), [open-source](), [processes](), [security](), [snapshots](), [ssecurity](), [testing](), [vulnerabilities]() ### AI overview This article explains how Firefox uses process separation and IPC to isolate lower-privilege content processes from the privileged parent process. It introduces snapshot fuzzing, a method for rewinding application state to make testing critical IPC interfaces more practical by avoiding costly browser restarts and reducing iteration latency. ### Source excerpt Process separation remains one of the most important parts of the Firefox security model and securing our IPC (Inter-Process Communication) interfaces is crucial to keep privileges in the different processes separated. We take a more detailed look at our newest tool for finding vulnerabilities in these interfaces - snapshot fuzzing. The post Snapshots for IPC Fuzzing appeared first on Mozilla Hacks - the Web developer blog. ## The legend about AIDL. Part 2. In Action DevFeed: [The legend about AIDL. Part 2. In Action]() Original publisher: [Read original article]() Author: Vladislav Puryev Published: 2021-01-16T14:50:18Z Content type: tutorial Language: en Sources: [Stories by Vladislav Puryev on Medium]() Topics: [Android](), [Process](), [Remote Procedure Call (RPC)](), [Code]() Tags: [aidl](), [android](), [code](), [ipc](), [process](), [rpc]() ### AI overview This tutorial explains how developers can use Android Interface Definition Language (AIDL), including its relationship to RPC and IDL concepts. It focuses on communication between applications and other processes through Android interprocess communication, with code and technical details. ### Source excerpt The legend of AIDL. Part 2. In Action Hello everybody. In previous article you could read about theoretical basics of Interface Definition Language and its main idea. Well, unlike the previous one, this part will contain a lot of code and technical details. Sometimes you will see internal parts of Android system, the parts that most of developers should not worry about in their works. The following material is dedicated to AIDL itself, how developer can use it, how it works and how RPC and IDL concepts are implemented in Android system. I hope you are interested and ready. Let's start! WARNING! The some code will be provided in shortened form. Full versions you can find in your IDE, in AOSP or Android Code Search. Please be careful, cause most of further code can be changed any time by Google developers, that is why some material can be obsolete and partially or completely wrong in the future, but actual for the moment of publication. This series of articles consist of three parts: The legend about AIDL. Part 1. The roots The legend about AIDL. Part 2. In Action (you are here) The legend about AIDL. Part 3. The crucial ingredient AIDL for applications developer I think, that there are just two general situations, when you really need to use Android Interface Definition Language: You have two (or more) applications and you are completely sure, that user will install one "main" application which can provide some functions for others. It means, that one of your applications must be exactly installed on user's device, cause other one (two, four and etc.) wouldn't give user some features without "basic application". It is possible to say, that your "basic application" is a server. You are developer of a new device, based on Android. May be some more usages are exist, but anyway all of them require AIDL power just for one goal -- communication between different processes (process is not always an application). Why so? Well, a lot of parts of Android system and different ap ## C++ DEV Update - July edition DevFeed: [C++ DEV Update - July edition]() Original publisher: [Read original article]() Author: Christian Reitwiessner Published: 2016-07-08T17:57:33Z Content type: news Language: en Sources: [Ethereum Foundation Blog]() Topics: [C++](), [Development](), [Blockchain](), [Benchmark](), [Remote Procedure Call (RPC)](), [JIT](), [Ubuntu]() Tags: [apache](), [benchmark](), [benchmarks](), [blockchain](), [c-plus-plus](), [dev](), [go](), [ipc](), [jit](), [native](), [proof-of-work](), [research-development](), [rpc](), [ubuntu](), [update]() ### AI overview An overview of work on the C++ Ethereum client, including proposed Apache 2.0 relicensing, new RPC endpoints for smart-contract testing, improvements to the EVM interpreter, and benchmark results comparing interpreter and JIT performance. ### Source excerpt Since the last C++ DEV Update, a lot of things happened in the engine room which were not really visible to the outside. This post wants to give an overview about what we are currently working on. Apart from the features side, Bob has been working on a proposed... ## Kafka Producer Pipeline for Ruby on Rails DevFeed: [Kafka Producer Pipeline for Ruby on Rails]() Original publisher: [Read original article]() Author: Simon Eskildsen Published: 2014-07-22T15:28:00Z Content type: article Language: en Sources: [Shopify Engineering](), [Shopify Engineering - Shopify Engineering]() Topics: [Kafka](), [Rails](), [Ruby](), [Containers](), [Go](), [data]() Tags: [architecture](), [container](), [containers](), [data](), [go](), [infrastructure](), [ipc](), [jvm](), [kafka](), [kernel](), [library](), [logs](), [queue](), [ruby](), [shopify]() ### AI overview This article describes how Shopify integrated Kafka with its Ruby on Rails and Go infrastructure. It explains the use of a Go-based Kafka producer and kernel-level SysV message queues to buffer events, support restarts, and tolerate Kafka downtime, followed by the operational challenges introduced by Docker containerization. ### Source excerpt In the early fall our infrastructure team was considering Kafka, a highly available message bus. We were looking to solve several infrastructure problems that had come up around that time. We were looking for a reliable way to collect event data and send it to our data warehouse. We were considering a more service-oriented architecture, and needed a standardized way of message passing between the components. We were starting to evaluate containerization of Shopify, and were searching for a way to get logs out of containers. We were intrigued by Kafka due to its highly available design. However, Kafka runs on the JVM, and its primary user, LinkedIn, runs a full JVM stack. Shopify is mainly Ruby on Rails and Go, so we had to figure out how to integrate Kafka into our infrastructure. ## 100,000 strong - CodeFactory server DevFeed: [100,000 strong - CodeFactory server]() Original publisher: [Read original article]() Published: 2013-03-12T00:00:00Z Content type: article Language: en Sources: [HackerEarth]() Topics: [C](), [C++](), [Java](), [Finagle](), [Remote Procedure Call (RPC)](), [Processes](), [servers](), [Development]() Tags: [c](), [c-plus-plus](), [development](), [distributed](), [distributed-system](), [ipc](), [java](), [process](), [server]() ### AI overview This article recounts the development of HackerEarth's CodeFactory server. It describes an early C-based code checker that compiled and ran C, C++, and Java programs, including process execution, inter-process communication, privilege limitations, and retry handling on a shared server. The article then explains the adoption of Apache Thrift and the implementation of a client-server architecture for distributed, cross-language services, followed by expansion of the evaluation engine to languages such as Perl, PHP, Python, Ruby, and Haskell. ### Source excerpt The Inception January 2012 was an idyllic time for us. Three of us had just teamed up to build something cool. There was no planning for the future, no sort of agreement - we were just three geeks sitting in the dorm room who wanted to build a product. We started working on MyCareerStack where there was supposed to be interview questions, tutorials etc. Soon, we realized that there was code editor needed, but that was easy. The harder part was that people don't only want to write code online, they want to run them. Now that I had never done before! What resulted then was a hacky few hundred lines of code in C, which could compile and run code in just C, C++ and Java. It might have been even the worst piece of code I had ever written, but it worked and it was sweet! /* create FIFO to be used here & later for IPC. */ char fifo_1[NAME_MAX]; createFilePath(fifo_1, id, dir, FIFO_FILE_1); umask(0); /* reset file creation mask. */ int readfd_1, writefd_1, readfd_2; if (mkfifo(fifo_1, S_IRWXU | S_IRWXG | S_IRWXO) < 0) err(1, NULL); /* Fork a child to exec the process: {id}_a.out */ pid_t pid; int status; signal(SIGALRM, handle_tle); /* change current working directory to mycareerstack */ chdir(RUNTIME_DIR); Wait, you haven't seen the ugly part yet! This will make you cringe, it made me too. See what the hell I am doing with re-tries, but it was required! int tries = 0; /* try the exec 100 times. */ while(tries < 100) { /* run the program. */ if(execl(executable, executable, (char*) 0) < 0) { // } ++tries; } printf("Couldn't run the program!"); _exit(0); There were some serious reasons for which this hack was done. We were hosted on a shared webfaction server, with no access to root. This meant I couldn't drop the user process privilege to any user with limited access permissions. I needed to create another user then with limited access which could be controlled by the original user. And again, I didn't know of any way to know if there is already a process running with privi ## CPU Cache Flushing Fallacy DevFeed: [CPU Cache Flushing Fallacy]() Original publisher: [Read original article]() Author: Martin Thompson (noreply@blogger.com) Published: 2013-02-14T12:22:00Z Content type: article Language: en Sources: [Mechanical Sympathy]() Topics: [Cache](), [cpu](), [x86](), [Latency](), [systems](), [intel]() Tags: [cache-coherence](), [core](), [cpu](), [cpu-cache](), [intel](), [ipc](), [latency](), [memory-heirarchy](), [performance](), [systems](), [x86]() ### AI overview The article explains why describing CPU-cache behavior as a cache "flush" can be misleading. It discusses cache hierarchies, interactions between caches and execution cores, memory latency, cache misses, and cache coherence, using Intel x86 server CPUs as a concrete example. ### Source excerpt Even from highly experienced technologists I often hear talk about how certain operations cause a CPU cache to "flush". This seems to be illustrating a very common fallacy about how CPU caches work, and how the cache sub-system interacts with the execution cores. In this article I will attempt to explain the function CPU caches fulfil, and how the cores, which execute our programs of instructions, interact with them. For a concrete example I will dive into one of the latest Intel x86 server CPUs. Other CPUs use similar techniques to achieve the same ends. Most modern systems that execute our programs are shared-memory multi-processor systems in design. A shared-memory system has a single memory resource that is accessed by 2 or more independent CPU cores. Latency to main memory is highly variable from 10s to 100s of nanoseconds. Within 100ns it is possible for a 3.0GHz CPU to process up to 1200 instructions. Each Sandy Bridge core is capable of retiring up to 4 instructions-per-cycle (IPC) in parallel. CPUs employ cache sub-systems to hide this latency and allow them to exercise their huge capacity to process instructions. Some of these caches are small, very fast, and local to each core; others are slower, larger, and shared across cores. Together with registers and main-memory, these caches make up our non-persistent memory hierarchy. Next time you are developing an important algorithm, try pondering that a cache-miss is a lost opportunity to have executed ~500 CPU instructions! This is for a single-socket system, on a multi-socket system you can effectively double the lost opportunity as memory requests cross socket interconnects. Memory Hierarchy Figure 1. For the circa 2012 Sandy Bridge E class servers our memory hierarchy can be decomposed as follows: Registers: Within each core are separate register files containing 160 entries for integers and 144 floating point numbers. These registers are accessible within a single cycle and constitute the fastest memory a ## Fun with my-Channels Nirvana and Azul Zing DevFeed: [Fun with my-Channels Nirvana and Azul Zing]() Original publisher: [Read original article]() Author: Martin Thompson (noreply@blogger.com) Published: 2012-03-22T17:55:00Z Content type: article Language: en Sources: [Mechanical Sympathy]() Topics: [Low Latency](), [Messaging](), [Java](), [Code]() Tags: [code](), [ipc](), [java](), [low-latency](), [messaging]() ### AI overview An engineering article examines my-Channels' low-latency messaging system under load. Profiling identified lock contention as the main limit on latency and throughput; replacing the standard Java executor with a lock-free executor produced tests showing about 10x better performance and enabled 16x more throughput. ### Source excerpt Since leaving LMAX I have been neglecting my blog a bit. This is not because I have not been doing anything interesting. Quite the opposite really, things have been so busy the blog has taken a back seat. I've been consulting for a number of hedge funds and product companies, most of which are super secretive. One company I have been spending quite a bit of time with is my-Channels, a messaging provider. They are really cool and have given me their blessing to blog about some of the interesting things I've been working on for them. For context, my-Channels are a messaging provider that specialise in delivering data to every device known to man over dodgy networks such as the Internet or your corporate WAN. They can deliver live financial market data to your desktop, laptop at home, or your iPhone, at the fastest possible rates. Lately, they have made the strategic move to enter the low-latency messaging space for the enterprise, and as part of this they have enlisted my services. They want to go low-latency without giving up the rich functionality their product offers which is giving me some interesting challenges. Just how bad is the latency of such a product when new to the low-latency space? I did not have high expectations because to be fair this was never their goal. After some initial tests, I'm thinking these guys are not in bad shape. They beat the crap out of most JMS implementations and it is going to be fun pushing them to the serious end of the low-latency space. OK enough of the basic tests, now it is time to get serious. I worked with them to create appropriate load tests and get the profilers running. No big surprises here, when we piled on the pressure, lock-contention came out as the biggest culprit limiting both latency and throughput. As we go down the list, lots of other interesting things showed up but let's follow good discipline and start at the top of the list. Good discipline for "Theory of Constraints" states that you always work on the mos