Hey, to all my #forth friends out there:
Is there any prior art for "message passing" in forth in the past?
I want my runtime to be able to "send" and "receive" messages, as the primary interface for e.g. getting RPC commands and returning responses.
Conversation
I've considered introducing a one-sided FIFO primitive, perhaps with a "name" or "idx" field baked in, to determine what to do with the message.
Though reading the Hubris design docs, I'm wondering if there is merit in a more synchronous pattern instead.
1
1
The use case would be for things like building a forth-driven I2C temperature driver, where you might want to regularly send the current temp, and perhaps the "other machine" could change some kind of setting, like a polling rate.
1
Or even a servo driver, where the "other machine" would send the desired position, or perhaps even query the current position.
2
Replying to
Ask 5 people you get 5 different answers I think.
I like the idea of blocking rendezvous channels (CSP) but my mind is mostly on hardware implementation. For the rest it depends a lot what context this runs in. Sync/Async messages, what's a task etc..
1
1
Other ways to look at it: a message is a program that runs in the receiver interpreter. You can optimize for small receiver code and let the protocol be whatever it wants to be as long as it gives simple receiver code.