ipc

[hawkw]

we should have this, especially because of "wasm does not have threads"

[hawkw]

also process management

[hawkw]

if everything runs in ring 0, do we need a distinction between "thread's" and "rprocesses"

[hawkw]

@hdevalence has some thoughts on transparent IPC/RPC i think?

[hdevalence]

i'm not sure how to do it, but if everything was "message passing" it would be very nice not to have a distinction between IPC and RPC. unfortunately because of spectre i think that not everything can run in ring 0, but instead of making a distinction between "threads" or "processes" or "tasks" etc., i think it would be good to have explicitly segmented security domains.

all of those words carry a lot of existing baggage, so instead we could invent some new ones -- say that the fundamental unit is called a "wask". wasks run independently and communicate by message passing built into the os. this message passing can have the same interface regardless of whether the two wasks are running on the same machine or different machines. additionally, wasks could be configured to run in "wask groups", which are internally implemented using the hardware for processes, but this is only a security boundary chosen by configuration, and does not affect the message passing interface.

[hdevalence]

(to do rpc we should also bundle an encryption layer into the message passing system)

[mystor]

There are a few types of resources which are valuable to allow sharing between processes, but don't make sense to share to remote machines. Stuff like shared memory, system handles, etc. can't really be shared to another machine over the network. I worry about preventing shared memory and sharing handles in order to keep the interface uniform for same and cross machine communication.

It might be worthwhile to have a more-limited message-passing API which supports doing cross-machine communication, as well as a shmem-based API for high-performance same-machine sharing of resources.

[hawkw]

It might be worthwhile to have a more-limited message-passing API which supports doing cross-machine communication, as well as a shmem-based API for high-performance same-machine sharing of resources.

it would be cool if uses of message-passing-based IPC could be transparently optimized to use shared mem when communicating locally

[mystor]

That would be good to do, and will probably influence the design of the API (e.g. requiring messages be page-aligned, and wasks losing access to pages after sending).

I'm a bit skeptical that we should get rid of shared memory entirely, though. There are other things which don't fit into a message-passing model where shared memory is useful, such as shared atomics, shared dynamic tables, etc. (For example, despite most messages using message-passing, we use a lot of other shared memory in Firefox).

[hdevalence]

i'm not an expert on any of this, but are there things that you definitely can't do with message passing that you could do with shared memory (vs. that are just faster/better with shared memory)? does it make sense to do only message passing at first, and then later add a different, opt-in mechanism for those things?

[hawkw]

some Kinds Of IPC that there are:

• like sockets (byte-stream oriented)
  • e.g. unix domain sockets
  • good for shuffling lots of bytes around
• (framed) message queue/fifo
• (typed?) event bus (probably multicast/pub-sub)
  • makes sense for system services to subscribe to different events
  • nice to have some kinda defined schema or way to define schemata, so you can register something like "i want keypress events" and get something sorta reasonable in return

[hdevalence]

does it make sense to think of a typed event bus as being a layer on top of a framed message system (i.e., framed messages whose data is in this particular format)?

also, what would be an example of an application that can't use a framed message queue and needs something like sockets?