| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit 1cca5142afbd76833deedfdb238230ac53424855.
This appears to be causing intermittent triple-faults and I don't know
why yet, so I'll just revert it to keep the tree in decent shape.
|
|
Background: DoubleBuffer is a handy buffer class in the kernel that
allows you to keep writing to it from the "outside" while the "inside"
reads from it. It's used for things like LocalSocket and PTY's.
Internally, it has a read buffer and a write buffer, but the two will
swap places when the read buffer is exhausted (by reading from it.)
Before this patch, it was internally implemented as two Vector<u8>
that we would swap between when the reader side had exhausted the data
in the read buffer. Now instead we preallocate a large KBuffer (64KB*2)
on DoubleBuffer construction and use that throughout its lifetime.
This removes all the kmalloc heap traffic caused by DoubleBuffers :^)
|
|
These types can be picked up by including <AK/Types.h>:
* u8, u16, u32, u64 (unsigned)
* i8, i16, i32, i64 (signed)
|
|
|
|
|
|
Dealing with the unsigned overflow propagation here just seems unreasonably
error prone. Let's limit ourselves to 2GB buffer sizes instead.
|
|
Since we know who's holding the lock, and we're gonna have to yield anyway,
we can just ask the scheduler to donate any remaining ticks to that process.
|
|
I'm pretty happy with the mechanism of AK::Lock for now.
|
|
|
|
|
|
|
|
|
