|
|
|
|
|
by benlivengood
1840 days ago
|
|
> (Sadly there’s no exact equivalent to Erlang-style message-passing, where producers target messages of arbitrary type at a specific consumer, which all go to the consumer’s single inbox; and where, if that inbox is full, then the message just “evaporates” en route Train stations plus circuits can do this. Trains can be configured to leave a station when not empty (after receiving a
message item of any type), and recipient stations can be disabled by a circuit if the receiver is full, causing the train to skip the station. The last station on the train's route would empty it before it goes back to waiting for a message item to deliver. |
|
N logistics bots are a much closer analogue to N scheduler threads each working in parallel to 1. take a message from a priority heap (really, to take a schedulable process from a priority heap and then run it to produce messages, but same difference) and then 2. synchronously shuttle that message to its destination queue.
I suppose you could get the same semantics with N parallel train tracks, one per scheduler-thread; plus an actual scheduler priority-queue implemented in circuits. But I feel like that's a "non-idiomatic case", in that, no matter how you designed your stations or where you put them, it'd be incredibly painful to design a loader/unloader for a "bus" of parallel train tracks. Especially if all the trains arrive together. It'd be a setup the devs would take one look at and say "that's too much of a kludge, and yet the kludgeyness is necessary, and that's our fault for not including a necessary abstraction. We'll just put in that abstraction."
(The alternative would be a mod that allows trains to pass through one-another on a track. Then you could have one train-line where each train cleanly represents a scheduler thread. No idea what would happen if they tried to stop at the same station at the same time, though. Ghost trains~)