In the current, centralized implementation, the plan was to have a ‘write’ operation waiting on acquisition of responsibility prevent later-queued ‘read’ operations from starting. This would prevent the situation where a slew of read-sequenced operations could prevent a single ‘write’ operation from ever realizing.
While re-designing responsibility, and re-implementing the old responsibility in a decentralized, queueless fashion, I realized that this places unreasonable ordering constraints on implementations. I'd rather ordering be explicit than implicit, obviously.
I need to figure out precisely why ordering like that might be necessary before reinstating it. For the moment, I'm planning to implement without such ordering at all (i.e. it's theoretically possible for a write-operation to be indefinitely postponed by a continuous series of unfortunately-timed reads.) If that actually turns out to be an issue, I can add implementation-specific heuristics to interleave the writes into the series of unordered reads; but I need to find out for sure if this is a semantic issue that needs to be solved by the design.
"reactor.coffee as of May 1st, 2015 (@ 588f11ba)"
"July 22nd, 2015 on the Pratchett devlog: ‘Queueless responsibility’"
In the current, centralized implementation, the plan was to have a ‘write’ operation waiting on acquisition of responsibility prevent later-queued ‘read’ operations from starting. This would prevent the situation where a slew of read-sequenced operations could prevent a single ‘write’ operation from ever realizing.
While re-designing responsibility, and re-implementing the old responsibility in a decentralized, queueless fashion, I realized that this places unreasonable ordering constraints on implementations. I'd rather ordering be explicit than implicit, obviously.
I need to figure out precisely why ordering like that might be necessary before reinstating it. For the moment, I'm planning to implement without such ordering at all (i.e. it's theoretically possible for a write-operation to be indefinitely postponed by a continuous series of unfortunately-timed reads.) If that actually turns out to be an issue, I can add implementation-specific heuristics to interleave the writes into the series of unordered reads; but I need to find out for sure if this is a semantic issue that needs to be solved by the design.