4 ms·
In my opinion, given that the C-ABI is pretty much the only cross language interface for transferring in memory data between components written in different lan
by drjasonharrison 4y ago
In my opinion, given that the C-ABI is pretty much the only cross language interface for transferring in memory data between components written in different languages, it is a pretty big blind spot not include into a new language a C-safe way of transferring memory.
Yes, you can open a socket or file and transfer your data that way, so someone had to then implement for the language the memory data protection mechanisms. Just expose them!
- tsimionescu 4y agoI don't think I suggested otherwise. I don't personally know of any non-esoteric language that doesn't support C interop - from Haskell to Common Lisp to Go to Java. What I'm pointing out is that the kernel can't help with C interop in any way, since process memory is by-and-large not managed by the kernel - certainly not at the level of individual objects. The problem of sending a Swift string to C and making sure it doesn't get "freed" by Swift is that the Swift runtime might overwrite that string if it is "freed", even though it's still being used by the C code, not that the kernel might mess with it. Even more, the risk when sharing memory with another language runtime is not even limitted to freeing. Many common languages have GCs which move in-use objects around in memory. This obviously can't work if that object was actually shared with a different runtime. In those, the object must not only be protected from being freed, but also from being moved around - hence the common concept of pinning it in memory. I think this makes it even more obvious that the OS can't help with this task - unless we want the OS to standardize on a GC that it imposes on all programs, and essentially no one wants that.