Thank you very much for the detailed answer. My use case is pretty simple but does require communications between jobs:
- One job to listen to events / responses from the web socket and pass it ordered as strings to a channel without back-pressure to be consumed by other job
- Second job that listens to channel messages and send each in order to the websocket.
- There will be a couple of jobs and channels for parsing JSON and handling different types of responses.
Basically it’s a tray-icon app that communicates with tiling window manager and reflect the changes in the system tray. In Rust I wrote an app with similar scope using tokio and while you’ll be right to say it’s overkill, it was pretty easy to implement 
.
Thinking again on the problem, there isn’t much difference in scope if I use jobs/channels or MBPs for this kind of scope. In both cases I need to listen and react on exceptions and disposals.
Maybe I’ll try to continue using MBPs and see how it goes…
Thanks