jer-irl

7 ms·

1. 1.▲
   by jer-irl 7mo ago

   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 i
2. 2.▲
   by jer-irl 7mo ago

   > 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 pa
3. 3.▲
   by jer-irl 7mo ago

   Thanks! The idea of launching additional components nearly "natively" from the shell was compelling to me early on, but I agree that shared libraries with a more opinionated "host program" is probably a more practical ap
4. 4.▲
   by jer-irl 7mo ago

   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
5. 5.▲
   by jer-irl 7mo ago

   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.
6. 6.▲
   by jer-irl 7mo ago

   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 me
7. 7.▲
   by jer-irl 7mo ago

   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
8. 8.▲
   Show HN: Threadprocs – executables sharing one address space (0-copy pointers)(github.com)

   64 points by jer-irl 7mo ago|46 comments