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

Rate limits, scheduling and preemption #114

SquidDev opened this Issue Feb 14, 2019 · 1 comment


None yet
1 participant
Copy link

SquidDev commented Feb 14, 2019

This has been kicking around my head for a couple of weeks, especially since 12e82af dropped, and given we just had an Indicent™ on SwitchCraft, I thought it might be as good a time as any to write up an issue on this:

Basically, we need a better way to prevent computers running amok. Or rather, when computers run amok, we need to reduce the impact that has on the rest of the server (and ideally on other computers). I think the best way in order to do this is as follows:

  • Introduce global limits for the amount of server time ComputerCraft can consume in a tick.
  • Allow pre-empting computers before they actually yield, reducing the risk of people blocking the computer thread.
  • Add some form of scheduling, so computers which do little work get server or computer time are not pushed aside by those which do a lot.

As far as work on the computer thread goes, it should be pretty trivial in a conceptual sense. The actual Computer implementation is a bit of a concurrency mess right now, so it'd be good to clean that up first. As far as scheduling goes, I think we can get away with something simple like waited-fair queuing (as used by Linux's CFS) - effectively pick whoever has used the least resources so far.

Server time is a little more complex. Unlike computers, tasks are executed in multiple places - turtles (on TE tick, executes commands for that computer), MainThread (in one batch for multiple computers) and on Plethora peripherals (on TE tick, commands tied to multiple computers). We need a way to spread time fairly between computers, while keeping as close to our budget as possible*.

I haven't found a satisfactory solution to this yet, without introducing high latencies or massive unfairness. Though, as hopefully most of the time we'll be well within our budget, I think we mostly need to worry about the case where a couple of computers are hogging all execution time.

* We're always going to go above our budget, as we don't know how long something will take before we do it.

It should also be possible to extend some of this code to the bandwidth limiting areas of #33, though I haven't fully thought though all of that yet.


This comment has been minimized.

Copy link
Member Author

SquidDev commented Mar 4, 2019

We've implemented the computer thread portions of this issue. I need to have a serious think about how best to handle the server tick scheduling - any ideas are welcome!

@SquidDev SquidDev referenced this issue Mar 20, 2019


Main thread task limiting #153

3 of 4 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.