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

11–20 of 48 posts

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

#11

Post by tombert »

furyofantares wrote: post #5
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…

I think it is possible for B to screw up A when you share a pointer but otherwise unlikely. B doing stuff with B's memory is unlikely to screw up A.

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 so thread B can screw up thread A's memory and juggling concurrency is hard and you need mutexes. Processes give isolation but at the cost of some overhead and IPC generally requiring copying.

I'm just not sure what this actually provides over vanilla pthreads. If I'm in charge of ensuring that the threadprocs don't screw with each other then I'm not sure this buys me anything.

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

#12

Post by jer-irl »

short_sells_poo wrote: post #8
whalesalad wrote: post #3

I feel like this could unlock some huge performance gains with Python. If you want to truly "defeat the GIL" you must use processes instead of threads. This could be a middle ground.

How would this really help python though? This doesn't solve the difficult problem, which is that python objects don't support parallel access by multiple threads/processes, no? Concurrent threads, yes, but only one thread can be operating on a python object at a time (I'm simplifying here for brevity). There are already means of passing around bulk data with zero copy characteristics in python, but there's a lot of…

I'm not familiar with CPython GC internals, but I there there are mechanisms for Python objects to be safely handed to C,C++ libraries and used there in parallel? Perhaps one could implement a handoff mechanism that uses those same mechanisms? Interesting idea!

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

#13

Post by fwsgonzo »

jeffbee wrote: post #9
fwsgonzo wrote: post #6

I actually just published a paper about something like this, which I implemented in both libriscv and TinyKVM called "Inter-Process Remote Execution (IPRE): Low-latency IPC/RPC using merged address spaces". Here is the abstract: This paper introduces Inter-Process Remote Execution (IPRE), whose primary function is enabling gated persistence for per-request isolation architectures with microsecond-latency access to pe…

Looks like you forgot the URL. Interested.

Best I can do is reply to an e-mail if someone asks for the paper, since it's not out yet. The e-mail ends with hotmail.

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

#14

Post by tombert »

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…

It's certainly an interesting idea and I'm not wholly opposed to it, though I certainly wouldn't use it as a default process scheduler for an OS (not that you were suggesting that). I would be very concerned about security stuff. If there's no process boundary saying that threadproc A can't grab threadproc B's memory, there could pretty easily be unintended leakages of potentially sensitive data.

Still, I actually do think there could be an advantage to this if you know you can trust the executables, and if the executables don't share any memory; if you know that you're not sharing memory, and you're only grabbing memory with malloc and the like, then there is an argument to be made that there's no need for the extra process overhead.

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

#15

Post by hun3 »

whalesalad wrote: post #3

I feel like this could unlock some huge performance gains with Python. If you want to truly "defeat the GIL" you must use processes instead of threads. This could be a middle ground.

This is exactly what subinterpreters are for! Basically isolated copies of Python in the same process.

https://docs.python.org/3/library/concurrent.interpreters.ht...

If you want a higher-level interface, there is InterpreterPoolExecutor:

https://docs.python.org/3/library/concurrent.futures.html#co...

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

#17

Post by PaulDavisThe1st »

Are you familiar with the Opal OS from UW CS&E during the 90s ? All tasks in a single system-wide address space, with h/w access control for memory regions.

> The Opal project is exploring a new operating system structure, tuned to the needs of complex applications, such as CAD/CAM, where a number of cooperating programs manipulate a large shared persistent database of objects. In Opal, all code and data exists with in a single, huge, shared address space. The single address space enhances sharing and cooperation, because addresses have a unique (for all time) interpretation. Thus, pointer-based data structures can be directly communicated and shared between programs at any time, and can be stored directly on secondary storage without the need for translation. This structure is simplified by the availability of a large address space, such as those provided by the DEC Alpha, MIPS, HP/PA-RISC, IBM RS6000, and future Intel processors.

> Protection in Opal is independent of the single address space; each Opal thread executes within a protection domain that defines which virtual pages it has the right to access. The rights to access a page can be easily transmitted from one process to another. The result is a much more flexible protection structure, permitting different (and dynamically changing) protection options depending on the trust relationship between cooperating parties. We believe that this organization can improve both the structure and performance of complex, cooperating applications.

> An Opal prototype has been built for the DEC Alpha platform on top of the Mach operating system.

https://homes.cs.washington.edu/~levy/opal/opal.html

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

#18

Post by jer-irl »

philipwhiuk wrote: post #16

This is basically 'De-ASLR' is it not?

Could you clarify what you mean by that? This does heavily rely on loaded code being position-independent, because the memory used will go into whatever regions `mmap(..., ~MAP_FIXED)` returns.

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

#19

Post by lifis »

"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should"

It's very cool, but would only be useful in some marginal cases, specifically if you don't want to modify the programs significantly and the reliability reduction is worth either the limited performance upside of avoiding mm switches or the ability to do somewhat easier shared memory.

Generally this problem would be better solved in either of these ways: 1. Recompile the modules as shared libraries (or statically link them together) and run them with a custom host program. This has less memory waste and faster startup. 2. Have processes that share memory via explicit shared memory mechanisms. This is more reliable.

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

#20

Post by jer-irl »

PaulDavisThe1st wrote: post #17

Are you familiar with the Opal OS from UW CS&E during the 90s ? All tasks in a single system-wide address space, with h/w access control for memory regions. > The Opal project is exploring a new operating system structure, tuned to the needs of complex applications, such as CAD/CAM, where a number of cooperating programs manipulate a large shared persistent database of objects. In Opal, all code and data exists with…

I wasn't but I'll have to read more! Some good relevant discussion here too https://news.ycombinator.com/item?id=7554921 . I wanted to keep this project in user-space, but there's a lot of interesting ground on the OS side of things too. Something like Theseus https://github.com/theseus-os/Theseus> is also interesting, providing similar protections (in theory) by enforced compiler invariants rather than hardware features.
Post reply on HN