Struct bonsaidb::files::direct::BufferedAppend

source ·

pub struct BufferedAppend<'a, Config, Database>where
    Config: FileConfig,
    Database: Connection + Clone,
{ /* private fields */ }

Expand description

A buffered std::io::Write and std::io::Seek implementor for a File.

Implementations§

source §

impl<'a, Config, Database> BufferedAppend<'a, Config, Database>
where Config: FileConfig, Database: Connection + Clone,

source

pub fn set_buffer_size(&mut self, capacity: usize) -> Result<(), Error>

Sets the size of the buffer. For optimal use, this should be a multiple of Config::BLOCK_SIZE.

If any data is already buffered, it will be flushed before the buffer is resized.

Trait Implementations§

source §

impl<'a, Config, Database> Drop for BufferedAppend<'a, Config, Database>
where Config: FileConfig, Database: Connection + Clone,

source §

fn drop(&mut self)

Executes the destructor for this type. Read more

source §

impl<'a, Config, Database> Write for BufferedAppend<'a, Config, Database>
where Config: FileConfig, Database: Connection + Clone,

source §

fn write(&mut self, data: &[u8]) -> Result<usize, Error>

Write a buffer into this writer, returning how many bytes were written. Read more

source §

fn flush(&mut self) -> Result<(), Error>

Flush this output stream, ensuring that all intermediately buffered contents reach their destination. Read more

1.36.0 · source§

fn write_vectored(&mut self, bufs: &[IoSlice<'_>]) -> Result<usize, Error>

Like write, except that it writes from a slice of buffers. Read more

source §

fn is_write_vectored(&self) -> bool

🔬This is a nightly-only experimental API. (can_vector)

Determines if this Writer has an efficient write_vectored implementation. Read more

1.0.0 · source§

fn write_all(&mut self, buf: &[u8]) -> Result<(), Error>

Attempts to write an entire buffer into this writer. Read more

source §

fn write_all_vectored(&mut self, bufs: &mut [IoSlice<'_>]) -> Result<(), Error>

🔬This is a nightly-only experimental API. (write_all_vectored)

Attempts to write multiple buffers into this writer. Read more

1.0.0 · source§

fn write_fmt(&mut self, fmt: Arguments<'_>) -> Result<(), Error>

Writes a formatted string into this writer, returning any error encountered. Read more

1.0.0 · source§

fn by_ref(&mut self) -> &mut Self
where Self: Sized,

Creates a “by reference” adapter for this instance of Write. Read more

Auto Trait Implementations§

§

impl<'a, Config, Database> RefUnwindSafe for BufferedAppend<'a, Config, Database>
where Config: RefUnwindSafe, Database: RefUnwindSafe, <Config as FileConfig>::Metadata: RefUnwindSafe,

§

impl<'a, Config, Database> !UnwindSafe for BufferedAppend<'a, Config, Database>

Blanket Implementations§

source §

impl<T> Any for T
where T: 'static + ?Sized,

source §

fn type_id(&self) -> TypeId

Gets the TypeId of self. Read more

§

impl<'a, T, E> AsTaggedExplicit<'a, E> for T
where T: 'a,

§

fn explicit(self, class: Class, tag: u32) -> TaggedParser<'a, Explicit, Self, E>

§

impl<'a, T, E> AsTaggedImplicit<'a, E> for T
where T: 'a,

§

fn implicit( self, class: Class, constructed: bool, tag: u32 ) -> TaggedParser<'a, Implicit, Self, E>

source §

impl<T> Borrow<T> for T
where T: ?Sized,

source §

fn borrow(&self) -> &T

Immutably borrows from an owned value. Read more

source §

impl<T> BorrowMut<T> for T
where T: ?Sized,

source §

fn borrow_mut(&mut self) -> &mut T

Mutably borrows from an owned value. Read more

§

impl<T> ExecutableCommand for T
where T: Write + ?Sized,

§

fn execute(&mut self, command: impl Command) -> Result<&mut T, Error>

Executes the given command directly.

The given command its ANSI escape code will be written and flushed onto Self.

Arguments

Command

The command that you want to execute directly.

Example

use std::io;
use crossterm::{ExecutableCommand, style::Print};

fn main() -> io::Result<()> {
     // will be executed directly
      io::stdout()
        .execute(Print("sum:\n".to_string()))?
        .execute(Print(format!("1 + 1= {} ", 1 + 1)))?;

      Ok(())

     // ==== Output ====
     // sum:
     // 1 + 1 = 2
}

Have a look over at the Command API for more details.

Notes

In the case of UNIX and Windows 10, ANSI codes are written to the given ‘writer’.
In case of Windows versions lower than 10, a direct WinAPI call will be made. The reason for this is that Windows versions lower than 10 do not support ANSI codes, and can therefore not be written to the given writer. Therefore, there is no difference between execute and queue for those old Windows versions.

source §

impl<T> From<T> for T

source §

fn from(t: T) -> T

Returns the argument unchanged.

§

impl<T> Instrument for T

§

fn instrument(self, span: Span) -> Instrumented<Self>

Instruments this type with the provided [Span], returning an Instrumented wrapper. Read more

§

fn in_current_span(self) -> Instrumented<Self>

Instruments this type with the current Span, returning an Instrumented wrapper. Read more

source §

impl<T, U> Into for T
where U: From<T>,

source §

fn into(self) -> U

Calls U::from(self).

That is, this conversion is whatever the implementation of From<T> for U chooses to do.

§

impl<T> QueueableCommand for T
where T: Write + ?Sized,

§

fn queue(&mut self, command: impl Command) -> Result<&mut T, Error>

Queues the given command for further execution.

Queued commands will be executed in the following cases:

When flush is called manually on the given type implementing io::Write.
The terminal will flush automatically if the buffer is full.
Each line is flushed in case of stdout, because it is line buffered.

Arguments

Command

The command that you want to queue for later execution.

Examples

use std::io::{self, Write};
use crossterm::{QueueableCommand, style::Print};

 fn main() -> io::Result<()> {
    let mut stdout = io::stdout();

    // `Print` will executed executed when `flush` is called.
    stdout
        .queue(Print("foo 1\n".to_string()))?
        .queue(Print("foo 2".to_string()))?;

    // some other code (no execution happening here) ...

    // when calling `flush` on `stdout`, all commands will be written to the stdout and therefore executed.
    stdout.flush()?;

    Ok(())

    // ==== Output ====
    // foo 1
    // foo 2
}

Have a look over at the Command API for more details.

Notes

In the case of UNIX and Windows 10, ANSI codes are written to the given ‘writer’.
In case of Windows versions lower than 10, a direct WinAPI call will be made. The reason for this is that Windows versions lower than 10 do not support ANSI codes, and can therefore not be written to the given writer. Therefore, there is no difference between execute and queue for those old Windows versions.

source §

impl<T> Same for T

§

type Output = T

Should always be Self

§

impl<W> SynchronizedUpdate for W
where W: Write + ?Sized,

§

fn sync_update<T>( &mut self, operations: impl FnOnce(&mut W) -> T ) -> Result<T, Error>

Performs a set of actions within a synchronous update.

Updates will be suspended in the terminal, the function will be executed against self, updates will be resumed, and a flush will be performed.

Arguments

Function

A function that performs the operations that must execute in a synchronized update.

Examples

use std::io;
use crossterm::{ExecutableCommand, SynchronizedUpdate, style::Print};

fn main() -> io::Result<()> {
    let mut stdout = io::stdout();

    stdout.sync_update(|stdout| {
        stdout.execute(Print("foo 1\n".to_string()))?;
        stdout.execute(Print("foo 2".to_string()))?;
        // The effects of the print command will not be present in the terminal
        // buffer, but not visible in the terminal.
        std::io::Result::Ok(())
    })?;

    // The effects of the commands will be visible.

    Ok(())

    // ==== Output ====
    // foo 1
    // foo 2
}

Notes

This command is performed only using ANSI codes, and will do nothing on terminals that do not support ANSI codes, or this specific extension.

When rendering the screen of the terminal, the Emulator usually iterates through each visible grid cell and renders its current state. With applications updating the screen a at higher frequency this can cause tearing.

This mode attempts to mitigate that.

When the synchronization mode is enabled following render calls will keep rendering the last rendered state. The terminal Emulator keeps processing incoming text and sequences. When the synchronized update mode is disabled again the renderer may fetch the latest screen buffer state again, effectively avoiding the tearing effect by unintentionally rendering in the middle a of an application screen update.

source §