21–30 of 48 posts
Earlier quoted context omitted.
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.
This gives me an impression that the paper has already been published and is available publicly for us to read.
"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…
Explicit shared memory regions is definitely the standard for this sort of a problem if you desire isolated address spaces. One area I want to explore further is using allocation/allocators that are aware of explicit shared memory regions, and perhaps ensuring that the regions get mmap'd to the same virtual address in all participants.
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)
Earlier quoted context omitted.
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.
> 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.
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.
Python has a wrapper on in the standard library [2], not sure about other languages
1. https://www.man7.org/linux/man-pages/man3/shm_open.3.html
2. https://docs.python.org/3/library/multiprocessing.shared_mem...
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…
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!
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…
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
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…
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!
Earlier quoted context omitted.
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 s…
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 any use case personally. (perhaps the author has a good one, its not impossible)