If you say “sorry, you have to write custom IPC for macOS because maybe you might want to share a texture” then Rust users are just not going to write multiprocess programs.
-
-
Current state is “sorry but to share textures you need to make them global so that all processes can read it”, that doesn’t sound good either.
1 reply 0 retweets 2 likes -
We shouldn’t give up on a cross-platform IPC abstraction just because of texture sharing, which is something that basically only browsers and window managers need to do anyway.
1 reply 0 retweets 1 like -
Sure, but Servo maybe shouldn't be using ipc-channel then.
2 replies 0 retweets 0 likes -
That being said, it's not just about texture sharing, ipc-channel IIRC works on macOS bv replacing the bootstrap Mach port and that's quite tacky in my book.
1 reply 0 retweets 0 likes -
I would say a lot of work, and I have no damn clue how to abstract over XPC services and make app and service bundles for macOS in a cargo-friendly way that still goes well with other OSes.
1 reply 0 retweets 0 likes -
Replying to @nokusu @BRIAN_____ and
I know virtually nothing about IPC on Linux or Windows. Some day I would like to see a tool to make multiprocess systems in Rust with actual different exes representing different services with which you could communicate, the tool handling all the plumbing for you.
1 reply 0 retweets 0 likes -
Replying to @nokusu @BRIAN_____ and
I've lived that world (COBRA; DCOM) and not just interprocess but multi-process/multi-machine and that turns into a fullblown configuration system, random IDL variant, etc. that have a life of their own and eventually their own cottage industry in books/consulting.
1 reply 0 retweets 1 like
Agreed with Brian. This could be a neat way for Rust to move beyond memory safety in security. (Making it easy to sandbox apps means more apps will hopefully sandbox themselves.)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.