common/org.js.lolifamily.minecraftmcp.exec/Capture

Capture

Accumulate, materialize once, seal. Backs the per-eval out and the run_command target=client chat window.

Sealing is the point, not an optimization: the append side reaches callers as a closure, and whoever holds it may be asynchronous and outlive this sink — after which it writes forever, unbounded, into something nobody will read, on whatever thread it happens to run on. take ends that.

Nothing is cached past take: the caller holds the only reference to the result, so an outliving writer pins no text.

Constructors

Capture

constructor()

Properties

lock

private val lock: Any

@Volatile

private var sb: StringBuilder?

Accumulator and seal flag in one: non-null == open. Volatile so write can check it WITHOUT the lock — the path an outliving writer takes for the rest of the process. Only the REFERENCE is volatile; the builder itself is still mutated under lock.

Functions

append

fun append(x: CharSequence)

Materialized by the caller, so no arbitrary toString() runs under the monitor, where it would stall every other writer. A mutable sequence is read at lock time — hand it over and drop it.

appendLine

fun appendLine(x: CharSequence)

take

fun take(): String

Consuming: a second call returns "" and logs. Retaining a copy to answer it would be exactly the pin this type exists to avoid.

write

private fun write(x: CharSequence, newline: Boolean)