From what I remember, in the Linux kernel, there's already barely any distinction between processes and threads, a thread is just a process that shares virtual memory with another process, you specify if memory should be shared or not when calling clone()

So we already have threads that do exactly what you're trying to do? Isn't it somewhat easier and less risky to just compile several programs into one binary? If you have no control over the programs you're trying to "fuse" (no source), then you probably don't want to fuse them, because it's very unsafe.

Maybe I don't understand something. I think it can work if you want processes with different lib versions or even different languages, but it sounds somewhat risky to pass data just like that (possible data corruption)

The code uses Linux's clone3() syscall under the hood: see https://github.com/jer-irl/threadprocs/blob/main/docs/02-imp...

The interesting thing is that it's loading existing binaries and executing them in a different way than usual. I think it's pretty clever (even if unsafe, as you mentioned).

This is a splendid example of a "hack" and I wish HN had more of these!

> I think it can work if you want processes with different lib versions or even different languages

This is exactly right, unrelated binaries can coexist, or different versions of the same binary, etc.

> it sounds somewhat risky to pass data just like that

This is also right! I started building an application framework that could leverage this and provide some protections on memory use: https://github.com/jer-irl/tproc-actors , but the model is inherently tricky, especially with elaborate data structures where ABI compatibility can be so brittle