Threadprocs
executables sharing one address space (0-copy pointers)
Details
- External ID
- 47491414
- Source
- HN
- Company
- —
- Product
- Threadprocs
- Website domain
- github.com
- Launched
- March 23, 2026
- Cohort
- —
- Upvotes
- 64
- Upvotes percentile
- 0.8603936039360394
- Tags
- —
- Fetched at
- Sept. 7, 2026, 9:26 p.m.
- Updated at
- Sept. 7, 2026, 9:26 p.m.
Description
This project launches multiple independent programs into a single shared virtual address space, while still behaving like separate processes (independent binaries, globals, and lifetimes). When threadprocs share their address space, pointers are valid across them with no code changes for well-behaved Linux binaries.Unlike threads, each threadproc is a standalone and semi-isolated process. Unlike dlopen-based plugin systems, threadprocs run traditional executables with a `main()` function. Unlike POSIX processes, pointers remain valid across threadprocs because they share the same address space.This means that idiomatic pointer-based data structures like `std::string` or `std::unordered_map` can be passed between threadprocs and accessed directly (with the usual data race considerations).This accomplishes a programming model somewhere between pthreads and multi-process shared memory IPC.The implementation relies on directing ASLR and virtual address layout at load time and implementing a user-space analogue of `exec()`, as well as careful manipulation of threadproc file descriptors, signals, etc. It is implemented entirely in unprivileged user space code: <https://github.com/jer-irl/threadprocs/blob/main/docs/02-imp...>.There is a simple demo demonstrating “cross-threadproc” memory dereferencing at <https://github.com/jer-irl/threadprocs/tree/main?tab=readme-...>, including a high-level diagram.This is relevant to systems of multiple processes with shared memory (often ring buffers or flat tables). These designs often require serialization or copying, and tend away from idiomatic C++ or Rust data structures. Pointer-based data structures cannot be passed directly.There are significant limitations and edge cases, and it’s not clear this is a practical model, but the project explores a way to relax traditional process memory boundaries while still structuring a system as independently launched components.
Enrichment
- Theme
- file transfer and sharing tools
- Vertical
- Horizontal
- Function
- Dev tools
- Audience
- Developer
- AI stance
- Not AI
- Project type
- Hobby / open-source project
- Normalized one-liner
- executables sharing memory address space with zero-copy pointers
- Manually corrected
- False
Could you build this?
No Running multiple distinct compiled executables within a single virtual address space while isolating their globals and lifetimes requires deep OS kernel, ELF loader, and linker-level hacking.
What it would actually take: Building this requires writing a custom user-space dynamic linker and ELF/Mach-O loader that maps distinct binary images into one virtual address space without symbol collisions or conflicting TLS (thread-local storage) regions. The hardest part is managing distinct static/global state, thread initialization, and libc runtime isolation so standard libraries do not corrupt each other when sharing pointer space. This demands world-class systems, compiler, and OS runtime expertise.
Discussion
20 comments analyzed.
Competitors mentioned: iceoryx - shared memory IPC with zero-copy for compatible data types, VMRPC - previous work on shared area memory protection, Solaris/Illumos Doors - similar RPC mechanism, dlopen-based plugin systems - alternative to executable loading, Erlang - message-passing concurrency model
Concerns raised: Removes address space isolation entirely, creating security/safety risks, Memory corruption risk when multiple processes access same data without proper locking, Breaks when running multiple instances with global state or incompatible library versions, Difficult to reason about code with shared memory and concurrency, CPU cache coherency issues with concurrent reads/writes to same memory
Feature requests: Support for heap-based and self-referential data structures, Call destructors for cleanup, Make Rust checker 'extra process' aware for shared memory scenarios, Support for data in nocopy encodings like Cap'n Proto or MessagePack across languages
Competitors
Other products that read as similar to this one — 107 launches clear the similarity bar, closest 8 shown.
Attention rank: #20 of 108 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).
Launched 143 days after the earliest competitor.
- I wrote a minimal memory allocator in C · hn · 2025-11-23 · 137 upvotes · similarity 0.50
- Scope-structured arena memory for C, O(1) cleanup, no GC/borrow checker · hn · 2026-04-15 · 5 upvotes · similarity 0.46
- Forkrun · hn · 2026-03-27 · 151 upvotes · similarity 0.45
- Lockstep · hn · 2026-03-16 · 8 upvotes · similarity 0.45
- Built a tiny interpreter from scratch in C to understand how they work · hn · 2025-11-12 · 5 upvotes · similarity 0.44
- cpx · hn · 2026-03-06 · 5 upvotes · similarity 0.42
- Sub-millisecond VM sandboxes using CoW memory forking · hn · 2026-03-17 · 311 upvotes · similarity 0.42
- A systems language with runtime reflection and no GC · hn · 2025-12-15 · 6 upvotes · similarity 0.41
Other launches for this product
- No other launches for this product.
Same idea, different domain
Nobody's really built a dev tools tool for Sales yet.