- Runners would set their active executor before starting resetting the
time, meaning it would be judged as running and terminated.
- Similarly, the cumulative time start was reset to 0, meaning the
computer had been judged to run for an impossibly long time.
- If a computer hit the terminate threshold, but not the hard abort
one, then we'd print the stack trace of the terminated thread - we
now do it before interrupting.
There's still race conditions here when terminating a computer, but
hopefully these changes will mean they never occur under normal
operations (only when a computer has run for far too long).
- Fix the timeout error message displaying utter rot.
- Don't resize the runner array. We don't handle this correctly, so
we shouldn't handle it at all.
- Increment virtualRuntime after a task has executed.
- The computer queue is a priority queue sorted by "virtual runtime".
- Virtual runtime is based on the time this task has executed, divided
by the number of pending tasks.
- We try to execute every task within a given period. Each computer is
allocated a fair share of that period, depending how many tasks are
in the queue. Once a computer has used more than that period, the
computer is paused and the next one resumed.
TimeoutState now introduces a TIMESLICE, which is the maximum period of
time a computer can run before we will look into pausing it.
When we have executed a task for more than this period, and if there are
other computers waiting to execute work, then we will suspend the
machine.
Suspending the machine sets a flag on the ComputerExecutor, and pauses
the "cumulative" time - the time spent handling this particular event.
When resuming the machine, we restart our timer and resume the machine.
Oh goodness, when will it end?
- Computer errors are shown in red.
- Lua machine operations provide whether they succeeded, and an
optional error message (reason bios failed to load, timeout error,
another Lua error), which is then shown to the user.
- Clear the Cobalt "thrown soft abort" flag when resuming, rather than
every n instructions.
- Computers will clear their "should start" flag once the time has
expired, irrespective of whether it turned on or not. Before
computers would immediately restart after shutting down if the flag
had been set much earlier.
Errors within the Lua machine are displayed in a more friendly
When closing a BufferedWriter, we close the underlying writer. As we're
using channels, this is an instance of sun.nio.cs.StreamEncoder. This
will attempt to flush the pending character.
However, if throwing an exception within .write errors, the flush will
fail and so the underlying stream is not closed. This was causing us to
leak file descriptors.
We fix this by introducing ChannelWrappers - this holds the wrapper
object (say, a BufferedWriter) and underlying channel. When closed, we
dispose of the wrapper, and then the channel. You could think of this as
doing a nested try-with-resources, rather than a single one.
Note, this is not related to JDK-6378948 - this occurs in the underlying
stream encoder instead.
- TimeoutState uses nanoseconds rather than milliseconds. While this is
slightly less efficient on Windows, it's a) not the bottleneck of Lua
execution and b) we need a monotonic counter, otherwise we could
fail to terminate computers if the time changes.
- Add an exception handler to all threads.
- Document several classes a little better - I'm not sure how useful
all of these are, but _hopefully_ it'll make the internals a little
more accessible.
- Move state management (turnOn, shutdown, etc...) event handling and
the command queue into a ComputerExecutor
- This means the computer thread now just handles running "work" on
computer executors, rather than managing a separate command queue +
requeuing it.
- Instead of setting soft/hard timeouts on the ILuaMachine, we instead
provide it with a TimeoutState instance. This holds the current abort
flags, which can then be polled within debug hooks.
This means the Lua machine has to do less state management, but also
allows a more flexible implementation of aborts.
- Soft aborts are now handled by the TimeoutState - we track when the
task was started, and now only need to check we're more than 7s since
then.
Note, these timers work with millisecond granularity, rather than
nano, as this invokes substantially less overhead.
- Instead of having n runners being observed with n managers, we now
have n runners and 1 manager (or Monitor).
The runners are now responsible for pulling work from the queue. When
the start to execute a task, they set the time execution commenced.
The monitor then just checks each runner every 0.1s and handles hard
aborts (or killing the thread if need be).
- Rename unload -> close to be a little more consistent
- Make pollAndResetChanged be atomic, so we don't need to aquire a lock
- Get the computer queue from the task owner, rather than a separate
argument.
Ideally we'd add a couple more tests in the future, but this'll do for
now.
The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad
ugly. It works though.
Prior to this change we would schedule a new task which attached
peripherals on the ComputerThread on the empty task queue. This had a
couple of issues:
- Slow running tasks on the computer thread could result in delays in
peripherals being attached (technically, though rarely seen in
practice).
- Now that the ComputerThread runs tasks at once, there was a race
condition in computers being turned on/off and peripherals being
attached/detached.
Note, while the documentation said that peripherals would only be
(at|de)tached on the computer thread, wired modems would attach on the
server thread, so this was not the case in practice.
One should be aware that peripherals are still detached on the
computer thread, most notably when turning a computer on/off.
This is almost definitely going to break some less well-behaved mods,
and possible some of the well behaved ones. I've tested this on SC, so
it definitely works fine with Computronics and Plethora.
- Restrict what items can be inserted into printers. They're now closer
to brewing stands or furnaces: nothing can go in the output slot,
only ink in the ink slot, and only paper in the paper slot.
- Fix build.gradle using the wrong version
- Trim the width of tables to fit when displaying on the client. Closes
#45. Note, our solution isn't perfect, as it will wordwrap too, but
it's adaquate for now.
When a turtle was unloaded but not actually disposed of, the
m_peripheral map hangs around. As a result, when creating a new
ServerComputer, the peripherals aren't considered changed and so they're
never attached.
Fixes#50.
Also fix that blumin' deprecated method which has been around for a wee
while now.
The Computer class currently has several resposiblities such as storing
id/label, managing redstone/peirpherals, handling management of the
computer (on/off/events) and updating the output.
In order to simplify this a little bit, we move our IAPIEnvironment
implementation into a separate file, and store all "world state"
(redstone + peripherals) in there. While we still need to have some
level of updating them within the main Computer instance, it's
substantially simpler.
- Fire close events instead of failure when open websockets error.
- Handle ping events. I thought I was doing this already, but this
requires a WebsocketProtocolHandler. Fixes#118
The latest version of Cobalt has several major changes, which I'm
looking forward to taking advantage of in the coming months:
- The Lua interpreter has been split up from the actual LuaClosure
instance. It now runs multiple functions within one loop, handling
pushing/popping and resuming method calls correctly.
This means we have a theoretically infinite call depth, as we're no
longer bounded by Java's stack size. In reality, this is limited to
32767 (Short.MAX_VALUE), as that's a mostly equivalent to the limits
PUC Lua exposes.
- The stack is no longer unwound in the event of errors. This both
simplifies error handling (not that CC:T needs to care about that)
but also means one can call debug.traceback on a now-dead coroutine
(which is more useful for debugging than using xpcall).
- Most significantly, coroutines are no longer each run on a dedicated
thread. Instead, yielding or resuming throws an exception to unwind
the Java stack and switches to a different coroutine.
In order to preserve compatability with CC's assumption about LuaJ's
threading model (namely that yielding blocks the thread), we also
provide a yieldBlock method (which CC:T consumes). This suspends the
current thread and switches execution to a new thread (see
SquidDev/Cobalt@b5ddf164f1 for more
details). While this does mean we need to use more than 1 thread,
it's still /substantially/ less than would otherwise be needed.
We've been running these changes on SwitchCraft for a few days now and
haven't seen any issues. One nice thing to observe is that the number of
CC thread has gone down from ~1.9k to ~100 (of those, ~70 are dedicated
to running coroutines). Similarly, the server has gone from generating
~15k threads over its lifetime, to ~3k. While this is still a lot, it's
a substantial improvement.
This is far more elegant than our weird method of baking things and
manually inserting them into the model map. Also means we no longer need
the whole turtle_dynamic thing.
We moved the direction call within the if block, but never actally
updated the condition! I'm on a roll of stupid bug fixes today, which
really isn't a good sign.
- Only have computers implement custom block drop logic: everything
else only drops in creative mode.
- Fix redstone inputs not being received correctly. Introduced in
8b86a954ee, yes I'm a silly billy.
- Only update the neighbour which changed.
- Convert terminals from a polling-based system to a more event-driven
one: they now accept an onChanged callback, which marks the parent as
dirty.
- Schedule ticks when monitors are marked as dirty.
- Add several missing @Overrides. This has nothing to do with the rest
of the changes, but I'm bad at good git practice.
- Merge BlockPeripheralBase and BlockPeripheral, as no other classes
extended the former.
- Make BlockPeripheral use ITilePeripheral instead of
TilePeripheralBase. This allows us to use other, non-ticking tiles
instead.
- Convert advanced and normal modems to extend from a generic
TileWirelessModemBase class, and thus neither now tick.
- Move getPeripheralType and getLabel from IPeripheralTile to
TilePeripheralBase. These were mostly constant on all other tiles, so
were rather redundant.
- Make TileAdvancedModem extend TileGeneric, and be non-ticking (using
similar logic to all other blocks).
- Move updateTick onto BlockGeneric/TileGeneric instead of the full
wired modem, as it is used by several tiles now.
- Make *Cable extend from *Generic, and schedule ticks instead of
running every tick.
We currently generate the crafting item once when the upgrade is first
created, and cache it for the duration of the game. As the item never
changes throughout the game, and constructing a stack is a little
expensive (we need to fire an event, etc...), the caching is worth
having.
However, some mods may register capabilities after we've constructed our
ItemStack. This means the capability will be present on other items but
not ours, meaning they are not considered equivalent, and thus the item
cannot be equipped.
In order to avoid this, we use compare items using their share-tag, like
Forge's IngredientNBT. This means the items must still be "mostly" the
same (same enchantements, etc...), but allow differing capabilities.
See NillerMedDild/Enigmatica2Expert#655 for the original bug report -
in this case, Astral Sourcery was registering the capability in init,
but we construct upgrades just before then.
- Move IDirectionalTile constraint from IPeripheralTile to
TilePeripheralBase.
- Make *WiredModemFull no longer inherit from *PeripheralBase. While
there is still some shared logic (namely in the syncing of "anim"),
it's largely fine as we don't store label or direction in NBT.
- Add a TickScheduler. This is a thread-safe version of
World.scheduleUpdate. We simply build a set of all TEs, and schedule
them to be updated the next tick.
- Make ModemState receive an "onChanged" listener, which is fired
whenever the modem changes.
- Make WiredModemFull no longer tick, instead scheduling updates when
it is first loaded and whenever the modem changes.
FileSystemMount was originally added to allow using ReadableByteChannels
instead of InputStreams. However, as zip files do not allow seeking,
there is no benefit of using them over the original JarMount (which we
need to preserve for backwards compatibility).
Instead of maintaining two near-identical mounts, we remove the
FileSystemMount and rewrite the JarMount implementation with several
improvements:
- Rewrite the jar scanning algorithm to be closer to 1.13+'s data pack
mount. This means we no longer require the jar file to have
directories before the file (though this was not a problem in
practice).
- Add all JarMounts to a ReferenceQueue, closing up the ZipFile when
they have been garbage collected (fixes#100).
- Cache the contents of all files for 60 seconds (with some constraints
on size). This allows us to seek on ROM files too (assuming they are
small), by reading the whole thing into memory.
The cache is shared across all mounts, and has a 64MiB limit, and
thus should not have an adverse impact on memory.
This is done in 1.13+ for items and blocks, so we might as well do it
for upgrades now. Note we can't do it for ender pocket modems, as the
upgrade ID is spelled incorrectly there.
- For those where placement is stored in the metadata (computers),
don't also set it in onBlockPlacedBy.
- Remove .getDefaultState(int, EnumFacing) override, as this means we
have more control over what is passed to us (namely, placer's
direction too).
"/computercraf" auto-completes to "/computercraft_copy" instead of
"/computercraft", which is rather annoying, as the former is not meant
to be used normally.
It's rather embarassing that it's been restructured _again_, but I think
this is a nice middle-ground. The previous implementation was written
mostly for Fabric, which doesn't always map perfectly to Forge.
- Move the message identifier into the registration phrase. It's not
really a property of the message itself, rather a property of the
registry, so better suited there.
- Move message handling into the message itself. Honestly, it was just
ending up being rather messy mixing the logic in two places.
This also means we can drop some proxy methods, as it's easier to
have conditionally loaded methods.
- Move network registry into a dedicated class, as that's what we're
doing for everything else.
This means we can avoid several rather ugly instances of getItemBlock
and a cast. We also derive the ItemBlock's registered name from the
block's name, which makes the register a little less ugly.
