Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Threadprocs – executables sharing one address space (0-copy pointers)

github.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Show HN: Threadprocs – executables sharing one address space (0-copy pointers)

#31

Post by tombert »

saidnooneever wrote: post #30
tombert wrote: post #11

Earlier quoted context omitted.

Sure but that's true of threads as well. The advantage of having these threadprocs is that there can be zero-copy sharing, which isn't necessarily bad but if they aren't copied then B could screw up A's stuff. If you're ok with threads keeping their own memory and not sharing then pthreads already do that competently without any additional library. The problem with threads is that there's a shared address space and s…

of they are zero copy sharing essentially they have both access to same data and this they can screw eachother up. you'd need to design the programs around this... which might aswell make u just use shared memory. without locking if multiple of these things would read or write to the same place the CPU will not appreciate it... u might read or write partials or garbage etc.? still a fun little project but i dont see…

The author mentioned in a sibling thread that the advantage is that they could be separate executables, which is admittedly a little neat. If processes don't need to share anything then there could be a performance advantage to having them live under the same address space without the overhead of a whole other process.

Re: Show HN: Threadprocs – executables sharing one address space (0-copy pointers)

#32

Post by tombert »

lstodd wrote: post #10
tombert wrote: post #2

Interesting. I gotta admit that my smell test tells me that this is a step backwards; at least naively (I haven't looked through the code thoroughly yet), this just kind of feels like we're going back to pre-protected-memory operating systems like AmigaOS; there are reasons that we have the process boundary and the overhead associated with it. If there are zero copies being shared across threadprocs, what's to stop T…

Judging by the description, it's exactly like AmigaOS, Windows 3.x or early Apple. Or MS-DOS things like DESQview. I fail to see the point - if you control the code and need performance so much that an occassional copy bites, you can as well just link it all into a single address space without those hoopjumps. It won't function as separate processes if it's modified to rely on passing pointers around anyway. And if y…

> Besides, what's wrong with shared memory?

I generally think that it's bad to share memory for anything with concurrency, simply because it can make it very hard to reason about the code. Mutexes are hard to get right for anything that's not completely trivial, and I find that it's almost always better to figure out a way to do work without directly sharing memory if possible (or do some kind of borrow/ownership thing like Rust to make it unambiguous who actually owns it). Mutexes can also make it difficult to performance test in my experience, since there can be weird choke points that don't show up in local testing and only ever show up in production.

Part of the reason I love Erlang so much is specifically because it really doesn't easily allow you to share memory. Everything is segmented and everything needs to be message-passed, so you aren't mucking around with mutexes and it's never ambiguous where memory is who who owns it. Erlang isn't the fastest language but since I'm not really dealing with locks the performance is generally much more deterministic for me.

Re: Show HN: Threadprocs – executables sharing one address space (0-copy pointers)

#33

Post by jeffbee »

fwsgonzo wrote: post #24
kjok wrote: post #21

Earlier quoted context omitted.

> I actually just published a paper... This gives me an impression that the paper has already been published and is available publicly for us to read.

Sorry about that, the conference was on Feb 2, and it's supposed to be out any day/week now. I don't have a date. There is a blog-style writeup here: https://fwsgonzo.medium.com/an-update-on-tinykvm-7a38518e57e... Not as rigorous as the paper, but the gist is there.

Thanks! I'll keep an eye out for the paper.

Re: Show HN: Threadprocs – executables sharing one address space (0-copy pointers)

#36

Post by jer-irl »

Retr0id wrote: post #34

> Unlike dlopen-based plugin systems, threadprocs run traditional executables with a `main()` function. Why not dlopen with something that calls plugin_main() (etc.) in its own thread?

Good call-out, and I think that's a more practical approach for most systems.

For this project, one of my goals was to impose the fewest dependencies possible on the loaded executables, and give the illusion that they're running in a fully independent process, with their own stdin/out/err and global runtime resources.

  "./my_prog abc" -> "launcher s.sock ./my_prog abc"
There's a rich design space if you impose "compile as .so with well-known entry point," and certainly that's what I'd explore for production apps that need this sort of a model.

Re: Show HN: Threadprocs – executables sharing one address space (0-copy pointers)

#38

Post by Chaosvex »

jer-irl wrote: post #7
tombert wrote: post #2

Interesting. I gotta admit that my smell test tells me that this is a step backwards; at least naively (I haven't looked through the code thoroughly yet), this just kind of feels like we're going back to pre-protected-memory operating systems like AmigaOS; there are reasons that we have the process boundary and the overhead associated with it. If there are zero copies being shared across threadprocs, what's to stop T…

Not negative at all, thanks for commenting. You're right that the answer is "nothing," and that this is a major trade-off inherent in the model. From a safety perspective, you'd need to be extremely confident that all threadprocs are well-behaved, though a memory-safe language would help some. The benefit is that you get process-like composition as separate binaries launched at separate times, with thread-like single…

I can understand the motivation here.

One of my hobby open source projects includes multiple services and I don't want to have to start and stop them individually just to test anything. They're designed to run standalone since it's a distributed system but having having to launch and stop each individual process was adding friction that lowered my enjoyment of working on it.

I recently ended up redesigning each service so they can run as a process or within a shared process that just uses LoadLibrary/dlopen (when not statically linked) to be able to quickly bring everything up and down at once, or restart a specific service if the binary changes.

Sure, everything will crash rather than just one service but it's lightweight (no need for complex deployment setups) and made the project far more enjoyable to work on. It's adequate for development work.

Another plus has been a much cleaner architecture after doing the necessary untangling required to get it working.

Re: Show HN: Threadprocs – executables sharing one address space (0-copy pointers)

#39

Post by ghthor »

jer-irl wrote: post #27
kgeist wrote: post #23

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 yo…

> 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/tpr…

Store all data in one of those nocopy encodings, capnproto/msgpack? Then each language can read the same memory but with the language specific SDK

Re: Show HN: Threadprocs – executables sharing one address space (0-copy pointers)

#40

Post by fc417fc802 »

Retr0id wrote: post #34

> Unlike dlopen-based plugin systems, threadprocs run traditional executables with a `main()` function. Why not dlopen with something that calls plugin_main() (etc.) in its own thread?

What if you're trying to run multiple instances of something that uses global state? Or that uses an incompatible library version? (I guess those are technically the same thing.)
Post reply on HN