Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple combinations, in series #12

Open
ELLIOTTCABLE opened this issue Mar 28, 2014 · 0 comments
Open

Multiple combinations, in series #12

ELLIOTTCABLE opened this issue Mar 28, 2014 · 0 comments

Comments

@ELLIOTTCABLE
Copy link
Member

If Paws is ever to be remotely performant, then the (many) lowest-level operations, constructed libside as Executions, need to be evaluated without every single combination causing the operation to be unstaged, and then cause it to sit through the reactor queue again.

Clearly, it's desirable that a truly basic series of operations on objects without overriden receivers be processable by optimised implementations during a single reactor-tick …

… but that raises a huge question: how can we allow such a series of operations to safely jump the reactor queue? The queue maintains order-of-operations; and if any operation is allowed to jump that queue in any situation, that operation could theoretically be out of order. (Not to mention fucking up mutability-safety by skipping the responsibility checks, eh?)

So: this needs thinking-through, to figure out if it's actually dangerous; and then, hopefully, munging-up of the design until we can safely do this. (I'm willing to make some small concessions at the design level for this, despite compramising on the design for the sake of performance being generally against my principles, because this is clearly one of the biggest bottlenecks in the entire design. Could easily find one extremely common ‘operation’ taking ten, or even fifty, ticks, instead of one or five. Ick.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant