A multiplexer of byte-orientated i/o. More...

#include "byte_io_multiplexer.hpp"

Inheritance diagram for llfio_v2_xxx::byte_io_multiplexer:

Classes
struct	_registered_buffer_type

struct	_synchronised_io_operation_state
	A synchronised i/o operation state. More...

struct	_unsynchronised_io_operation_state
	An unsynchronised i/o operation state. More...

struct	awaitable
	A convenience coroutine awaitable type returned by `.co_read()`, `.co_write()` and `.co_barrier()`. Blocks execution if no i/o multiplexer has been set on this handle! More...

struct	buffer_type

struct	check_for_any_completed_io_statistics
	Statistics about the just returned `wait_for_completed_io()` operation. More...

struct	const_buffer_type

struct	implementation_information_t
	The implementation information returned. More...

struct	io_operation_state
	An interface to a state for an i/o operation scheduled against an i/o multiplexer. More...

struct	io_operation_state_visitor
	Called by an i/o operation state to inform you of state change. Note that the i/o operation state lock is HELD during these calls! More...

struct	io_request
	The i/o request type used by this handle. Guaranteed to be `TrivialType` apart from construction, and `StandardLayoutType`. More...

struct	io_result
	The i/o result type used by this handle. Guaranteed to be `TrivialType` apart from construction. More...

Public Types
enum class	barrier_kind : uint8_t { nowait_view_only , wait_view_only , nowait_data_only , wait_data_only , nowait_all , wait_all }
	The kinds of write reordering barrier which can be performed. More...

using	path_type = handle::path_type

using	extent_type = handle::extent_type

using	size_type = handle::size_type

using	mode = handle::mode

using	creation = handle::creation

using	caching = handle::caching

using	flag = handle::flag

using	registered_buffer_type = std::shared_ptr< _registered_buffer_type >
	The registered buffer type used by this handle.

using	buffers_type = span< buffer_type >
	The scatter buffers type used by this handle. Guaranteed to be `TrivialType` apart from construction, and `StandardLayoutType`.

using	const_buffers_type = span< const_buffer_type >
	The gather buffers type used by this handle. Guaranteed to be `TrivialType` apart from construction, and `StandardLayoutType`.

Public Member Functions
	byte_io_multiplexer (byte_io_multiplexer &&)=default

	byte_io_multiplexer (const byte_io_multiplexer &)=delete

byte_io_multiplexer &	operator= (byte_io_multiplexer &&)=default

byte_io_multiplexer &	operator= (const byte_io_multiplexer &)=delete

virtual implementation_information_t	implementation_information () const noexcept=0
	Returns implementation information about an i/o multiplexer.

virtual result< uint8_t >	do_byte_io_handle_register (byte_io_handle *) noexcept

virtual result< void >	do_byte_io_handle_deregister (byte_io_handle *) noexcept
	Implements `byte_io_handle` deregistration.

virtual result< uint8_t >	do_byte_io_handle_register (listening_byte_socket_handle *) noexcept

virtual result< void >	do_byte_io_handle_deregister (listening_byte_socket_handle *) noexcept
	Implements `listening_byte_socket_handle` deregistration.

virtual size_t	do_byte_io_handle_max_buffers (const byte_io_handle *h) const noexcept
	Implements `byte_io_handle::max_buffers()`

virtual result< registered_buffer_type >	do_byte_io_handle_allocate_registered_buffer (byte_io_handle *h, size_t &bytes) noexcept
	Implements `byte_io_handle::allocate_registered_buffer()`

virtual std::pair< size_t, size_t >	io_state_requirements () noexcept=0
	Returns the number of bytes, and alignment required, for an `io_operation_state` for this multiplexer.

virtual io_operation_state *	construct (span< byte > storage, byte_io_handle _h, io_operation_state_visitor _visitor, registered_buffer_type &&b, deadline d, io_request< buffers_type > reqs) noexcept=0
	Constructs either a `unsynchronised_io_operation_state` or a `synchronised_io_operation_state` for a read operation into the storage provided. The i/o is not initiated. The storage must meet the requirements from `state_requirements()`.

virtual io_operation_state *	construct (span< byte > storage, byte_io_handle _h, io_operation_state_visitor _visitor, registered_buffer_type &&b, deadline d, io_request< const_buffers_type > reqs) noexcept=0
	Constructs either a `unsynchronised_io_operation_state` or a `synchronised_io_operation_state` for a write operation into the storage provided. The i/o is not initiated. The storage must meet the requirements from `state_requirements()`.

virtual io_operation_state *	construct (span< byte > storage, byte_io_handle _h, io_operation_state_visitor _visitor, registered_buffer_type &&b, deadline d, io_request< const_buffers_type > reqs, barrier_kind kind) noexcept=0
	Constructs either a `unsynchronised_io_operation_state` or a `synchronised_io_operation_state` for a barrier operation into the storage provided. The i/o is not initiated. The storage must meet the requirements from `state_requirements()`.

virtual io_operation_state *	construct (span< byte > storage, byte_socket_handle _h, io_operation_state_visitor _visitor, deadline d, const ip::address &) noexcept
	Constructs either a `unsynchronised_io_operation_state` or a `synchronised_io_operation_state` for a `byte_socket_handle` read operation into the storage provided. The i/o is not initiated. The storage must meet the requirements from `state_requirements()`.

virtual io_operation_state *	construct (span< byte > storage, listening_byte_socket_handle _h, io_operation_state_visitor _visitor, deadline d, std::pair< byte_socket_handle, ip::address > &) noexcept
	Constructs either a `unsynchronised_io_operation_state` or a `synchronised_io_operation_state` for a `listening_byte_socket_handle` read operation into the storage provided. The i/o is not initiated. The storage must meet the requirements from `state_requirements()`.

virtual io_operation_state_type	init_io_operation (io_operation_state *state) noexcept=0
	Initiates the i/o in a previously constructed state. Note that you should always call `.flush_inited_io_operations()` after you finished initiating i/o. After this call returns, you cannot relocate in memory `state` until `is_finished(state->current_state())` returns true.

virtual io_operation_state *	construct_and_init_io_operation (span< byte > storage, byte_io_handle _h, io_operation_state_visitor _visitor, registered_buffer_type &&b, deadline d, io_request< buffers_type > reqs) noexcept
	Combines `.construct()` with `.init_io_operation()` in a single call for improved efficiency.

virtual io_operation_state *	construct_and_init_io_operation (span< byte > storage, byte_io_handle _h, io_operation_state_visitor _visitor, registered_buffer_type &&b, deadline d, io_request< const_buffers_type > reqs) noexcept
	Combines `.construct()` with `.init_io_operation()` in a single call for improved efficiency.

virtual io_operation_state *	construct_and_init_io_operation (span< byte > storage, byte_io_handle _h, io_operation_state_visitor _visitor, registered_buffer_type &&b, deadline d, io_request< const_buffers_type > reqs, barrier_kind kind) noexcept
	Combines `.construct()` with `.init_io_operation()` in a single call for improved efficiency.

virtual io_operation_state *	construct_and_init_io_operation (span< byte > storage, byte_socket_handle _h, io_operation_state_visitor _visitor, deadline d, const ip::address &addr) noexcept
	Combines `.construct()` with `.init_io_operation()` in a single call for improved efficiency.

virtual io_operation_state *	construct_and_init_io_operation (span< byte > storage, listening_byte_socket_handle _h, io_operation_state_visitor _visitor, deadline d, std::pair< byte_socket_handle, ip::address > &req) noexcept
	Combines `.construct()` with `.init_io_operation()` in a single call for improved efficiency.

virtual result< void >	flush_inited_io_operations () noexcept
	Flushes any previously initiated i/o, if necessary for this i/o multiplexer.

virtual io_operation_state_type	check_io_operation (io_operation_state *op) noexcept
	Asks the system for the current state of the i/o, returning its current state.

virtual result< io_operation_state_type >	cancel_io_operation (io_operation_state *op, deadline d={}) noexcept=0
	Cancel an initiated i/o, returning its current state if successful.

virtual result< check_for_any_completed_io_statistics >	check_for_any_completed_io (deadline d=std::chrono::seconds(0), size_t max_completions=(size_t) -1) noexcept=0
	Checks all i/o initiated on this i/o multiplexer to see which have completed, trying without guarantee to complete no more than `max_completions` completions or finisheds, and not to exceed `d` of waiting (this function never fails with timed out).

virtual result< void >	wake_check_for_any_completed_io () noexcept=0
	Can be called from any thread to wake any other single thread currently blocked within `check_for_any_completed_io()`. Which thread is woken is not specified.

constexpr	handle ()

constexpr	handle (native_handle_type h, flag flags=flag::none) noexcept

	handle (const handle &)=delete

constexpr	handle (handle &&o) noexcept

flag	flags () const noexcept
	The flags this handle was opened with.

	QUICKCPPLIB_BITFIELD_BEGIN_T (flag, uint16_t)
	Bitwise flags which can be specified. More...

void	swap (handle &o) noexcept
	Swap with another instance.

virtual result< path_type >	current_path () const noexcept

virtual result< void >	close () noexcept
	Immediately close the native handle type managed by this handle.

result< handle >	clone () const noexcept

virtual native_handle_type	release () noexcept
	Release the native handle type managed by this handle.

bool	is_valid () const noexcept
	True if the handle is valid (and usually open)

bool	is_readable () const noexcept
	True if the handle is readable.

bool	is_writable () const noexcept
	True if the handle is writable.

bool	is_append_only () const noexcept
	True if the handle is append only.

virtual result< void >	set_append_only (bool enable) noexcept
	EXTENSION: Changes whether this handle is append only or not. More...

bool	is_multiplexable () const noexcept
	True if multiplexable.

bool	is_nonblocking () const noexcept
	True if nonblocking.

bool	is_seekable () const noexcept
	True if seekable.

bool	requires_aligned_io () const noexcept
	True if requires aligned i/o.

bool	is_kernel_handle () const noexcept
	True if `native_handle()` is a valid kernel handle.

bool	is_regular () const noexcept
	True if a regular file or device.

bool	is_directory () const noexcept
	True if a directory.

bool	is_symlink () const noexcept
	True if a symlink.

bool	is_pipe () const noexcept
	True if a pipe.

bool	is_socket () const noexcept
	True if a socket.

bool	is_multiplexer () const noexcept
	True if a multiplexer like BSD kqueues, Linux epoll or Windows IOCP.

bool	is_process () const noexcept
	True if a process.

bool	is_section () const noexcept
	True if a memory section.

bool	is_allocation () const noexcept
	True if a memory allocation.

bool	is_path () const noexcept
	True if a path or a directory.

bool	is_tls_socket () const noexcept
	True if a TLS socket.

bool	is_http_socket () const noexcept
	True if a HTTP socket.

caching	kernel_caching () const noexcept
	Kernel cache strategy used by this handle.

bool	are_reads_from_cache () const noexcept
	True if the handle uses the kernel page cache for reads.

bool	are_writes_durable () const noexcept
	True if writes are safely on storage on completion.

bool	are_safety_barriers_issued () const noexcept
	True if issuing safety fsyncs is on.

native_handle_type	native_handle () const noexcept
	The native handle used by this handle.

Static Protected Member Functions
static io_result< buffers_type >	_result_type_from_io_operation_state (io_operation_state state, buffers_type ) noexcept

static io_result< const_buffers_type >	_result_type_from_io_operation_state (io_operation_state state, const_buffers_type ) noexcept

Protected Attributes
union {
native_handle_type _v

struct {
intptr_t _padding0_

uint32_t _padding1_

flag flags

uint16_t _padding2_

} _

};

Static Protected Attributes
static constexpr size_t	_awaitable_size = 128

Detailed Description

A multiplexer of byte-orientated i/o.

LLFIO does not provide out-of-the-box multiplexing of byte i/o, however it does provide the ability to create byte_io_handle instances with the handle::flag::multiplexable set. With that flag set, the following LLFIO classes change how they create handles with the kernel:

LLFIO i/o class	POSIX	Windows
`directory_handle`	No effect	Creates `HANDLE` as `OVERLAPPED`
`file_handle`	No effect	Creates `HANDLE` as `OVERLAPPED`
`map_handle`	No effect	No effect
`mapped_file_handle`	No effect	Creates `HANDLE` as `OVERLAPPED`, but i/o is to map not file
`pipe_handle`	Creates file descriptor as non-blocking	Creates `HANDLE` as `OVERLAPPED`
`section_handle`	No effect	Creates `HANDLE` as `OVERLAPPED`
`socket_handle`	Creates file descriptor as non-blocking	Creates `HANDLE` as `OVERLAPPED` and as non-blocking
`symlink_handle`	No effect	Creates `HANDLE` as `OVERLAPPED`

If the i/o handle's multiplexer pointer is not null, the multiplexer instance is invoked to implement byte_io_handle::read(), byte_io_handle::write() and byte_io_handle::barrier() by constructing an i/o operation state on the stack, calling .init_io_operation() followed by .flush_inited_io_operations(), and then spinning on .check_io_operation() and .check_for_any_completed_io() with the deadline specified to the original blocking operation.

If the i/o handle's multiplexer pointer is null, byte_io_handle::read(), byte_io_handle::write() and byte_io_handle::barrier() all use virtually overridable implementations. The default implementations emulate blocking semantics using the kernel's i/o poll function (literally poll() on POSIX, NtWaitForSingleObject() on Windows) to sleep the thread until at least one byte of i/o occurs, or the deadline specified is exceeded. This, obviously enough, can double the number of kernel syscalls done per i/o, so using handles with the handle::flag::multiplexable flag set is not wise unless you really need non-infinite deadline i/o.

Member Enumeration Documentation

◆ barrier_kind

enum llfio_v2_xxx::byte_io_multiplexer::barrier_kind : uint8_t

strong

The kinds of write reordering barrier which can be performed.

Enumerator
nowait_view_only	Barrier mapped data only, non-blocking. This is highly optimised on NV-DIMM storage, but consider using `nvram_barrier()` for even better performance.
wait_view_only	Barrier mapped data only, block until it is done. This is highly optimised on NV-DIMM storage, but consider using `nvram_barrier()` for even better performance.
nowait_data_only	Barrier data only, non-blocking. This is highly optimised on NV-DIMM storage, but consider using `nvram_barrier()` for even better performance.
wait_data_only	Barrier data only, block until it is done. This is highly optimised on NV-DIMM storage, but consider using `nvram_barrier()` for even better performance.
nowait_all	Barrier data and the metadata to retrieve it, non-blocking.
wait_all	Barrier data and the metadata to retrieve it, block until it is done.

   {
     nowait_view_only,  //!< Barrier mapped data only, non-blocking. This is highly optimised on NV-DIMM storage, but consider using `nvram_barrier()` for even better performance.
     wait_view_only,  //!< Barrier mapped data only, block until it is done. This is highly optimised on NV-DIMM storage, but consider using `nvram_barrier()` for even better performance.
     nowait_data_only,  //!< Barrier data only, non-blocking. This is highly optimised on NV-DIMM storage, but consider using `nvram_barrier()` for even better performance.
     wait_data_only,  //!< Barrier data only, block until it is done. This is highly optimised on NV-DIMM storage, but consider using `nvram_barrier()` for even better performance.
     nowait_all,  //!< Barrier data and the metadata to retrieve it, non-blocking.
     wait_all     //!< Barrier data and the metadata to retrieve it, block until it is done.
   };

Member Function Documentation

◆ clone()

result<handle> llfio_v2_xxx::handle::clone ( ) const

inlinenoexceptinherited

Clone this handle (copy constructor is disabled to avoid accidental copying)

Errors returnable\n Any of the values POSIX dup() or DuplicateHandle() can return.

◆ current_path()

virtual result<path_type> llfio_v2_xxx::handle::current_path ( ) const

inlinevirtualnoexceptinherited

Returns the current path of the open handle as said by the operating system. Note that you are NOT guaranteed that any path refreshed bears any resemblance to the original, some operating systems will return some different path which still reaches the same inode via some other route e.g. hardlinks, dereferenced symbolic links, etc. Windows and Linux correctly track changes to the specific path the handle was opened with, not getting confused by other hard links. MacOS nearly gets it right, but under some circumstances e.g. renaming may switch to a different hard link's path which is almost certainly a bug.

If LLFIO was not able to determine the current path for this open handle e.g. the inode has been unlinked, it returns an empty path. Be aware that FreeBSD can return an empty (deleted) path for file inodes no longer cached by the kernel path cache, LLFIO cannot detect the difference. FreeBSD will also return any path leading to the inode if it is hard linked. FreeBSD does implement path retrieval for directory inodes correctly however, and see algorithm::cached_parent_handle_adapter<T> for a handle adapter which makes use of that.

On Linux if /proc is not mounted, this call fails with an error. All APIs in LLFIO which require the use of current_path() can be told to not use it e.g. flag::disable_safety_unlinks. It is up to you to detect if current_path() is not working, and to change how you call LLFIO appropriately.

On Windows, you will almost certainly get back a path of the form \!!\Device\HarddiskVolume10\Users\ned\.... See path_view for what all the path prefix sequences mean, but to summarise the \!!\ prefix is LLFIO-only and will not be accepted by other Windows APIs. Pass LLFIO derived paths through the function to_win32_path() to Win32-ise them. This function is also available on Linux where it does nothing, so you can use it in portable code.

Warning: This call is expensive, it always asks the kernel for the current path, and no checking is done to ensure what the kernel returns is accurate or even sensible. Be aware that despite these precautions, paths are unstable and can change randomly at any moment. Most code written to use absolute file systems paths is racy, so don't do it, use path_handle to fix a base location on the file system and work from that anchor instead!

Memory Allocations\n At least one malloc for the path_type, likely several more.

See also: algorithm::cached_parent_handle_adapter<T> which overrides this with an implementation based on retrieving the current path of a cached handle to the parent directory. On platforms with instability or failure to retrieve the correct current path for regular files, the cached parent handle adapter works around the problem by taking advantage of directory inodes not having the same instability problems on any platform.

Reimplemented in llfio_v2_xxx::symlink_handle, and llfio_v2_xxx::process_handle.

◆ do_byte_io_handle_register() [1/2]

virtual result<uint8_t> llfio_v2_xxx::byte_io_multiplexer::do_byte_io_handle_register ( byte_io_handle * )

inlinevirtualnoexcept

Implements byte_io_handle registration. The bottom two bits of the returned value are set into _v.behaviour's _multiplexer_state_bit0 and _multiplexer_state_bit

540 { return (uint8_t) 0; }

◆ do_byte_io_handle_register() [2/2]

virtual result<uint8_t> llfio_v2_xxx::byte_io_multiplexer::do_byte_io_handle_register ( listening_byte_socket_handle * )

inlinevirtualnoexcept

Implements listening_byte_socket_handle registration. The bottom two bits of the returned value are set into _v.behaviour's _multiplexer_state_bit0 and _multiplexer_state_bit

546 { return errc::operation_not_supported; }

◆ handle() [1/4]

constexpr llfio_v2_xxx::handle::handle

inlineconstexpr

Todo:: Why is io_result<buffers_type> not a standard layout type?

       : _v()
   {
   }  // NOLINT

◆ handle() [2/4]

llfio_v2_xxx::handle::handle

delete

Todo:: Why is io_result<buffers_type> not a standard layout type?

◆ handle() [3/4]

constexpr llfio_v2_xxx::handle::handle

inlineconstexprnoexcept

Todo:: Why is io_result<buffers_type> not a standard layout type?

       : _v(std::move(o._v))
   {
     o._v = native_handle_type();
   }

◆ handle() [4/4]

constexpr llfio_v2_xxx::handle::handle

inlineexplicitconstexprnoexcept

Todo:: Why is io_result<buffers_type> not a standard layout type?

       : _v(std::move(h), /* special move constructor to work around a constexpr bug in clang*/ uint16_t(flags))
   {
   }

◆ QUICKCPPLIB_BITFIELD_BEGIN_T()

llfio_v2_xxx::handle::QUICKCPPLIB_BITFIELD_BEGIN_T	(	flag	,
		uint16_t
	)

inlineinherited

Bitwise flags which can be specified.

< No flags

Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by path() upon the call of close() if and only if the inode matches. On Windows, if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous editions of Windows, the file entry does not disappears but becomes unavailable for anyone else to open with an errc::resource_unavailable_try_again error return. Because this is confusing, unless the win_disable_unlink_emulation flag is also specified, this POSIX behaviour is somewhat emulated by LLFIO on older Windows by renaming the file to a random name on close() causing it to appear to have been unlinked immediately.

Some kernel caching modes have unhelpfully inconsistent behaviours in getting your data onto storage, so by default unless this flag is specified LLFIO adds extra fsyncs to the following operations for the caching modes specified below: truncation of file length either explicitly or during file open. closing of the handle either explicitly or in the destructor.

Additionally on Linux only to prevent loss of file metadata: On the parent directory whenever a file might have been created. On the parent directory on file close.

This only occurs for these kernel caching modes: caching::none caching::reads caching::reads_and_metadata caching::safety_barriers

file_handle::unlink() could accidentally delete the wrong file if someone has renamed the open file handle since the time it was opened. To prevent this occuring, where the OS doesn't provide race free unlink-by-open-handle we compare the inode of the path we are about to unlink with that of the open handle before unlinking.

Warning: This does not prevent races where in between the time of checking the inode and executing the unlink a third party changes the item about to be unlinked. Only operating systems with a true race-free unlink syscall are race free.

Ask the OS to disable prefetching of data. This can improve random i/o performance.

Ask the OS to maximise prefetching of data, possibly prefetching the entire file into kernel cache. This can improve sequential i/o performance.

< See the documentation for unlink_on_first_close

Microsoft Windows NTFS, having been created in the late 1980s, did not originally implement extents-based storage and thus could only represent sparse files via efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000), a proper extents-based on-storage representation was added, thus allowing only 64Kb extent chunks written to be stored irrespective of whatever the maximum file extent was set to.

For various historical reasons, extents-based storage is disabled by default in newly created files on NTFS, unlike in almost every other major filing system. You have to explicitly "opt in" to extents-based storage.

As extents-based storage is nearly cost free on NTFS, LLFIO by default opts in to extents-based storage for any empty file it creates. If you don't want this, you can specify this flag to prevent that happening.

Filesystems tend to be embarrassingly parallel for operations performed to different inodes. Where LLFIO performs i/o to multiple inodes at a time, it will use OpenMP or the Parallelism or Concurrency standard library extensions to usually complete the operation in constant rather than linear time. If you don't want this default, you can disable default using this flag.

Microsoft Windows NTFS has the option, when creating a directory, to set whether leafname lookup will be case sensitive. This is the only way of getting exact POSIX semantics on Windows without resorting to editing the system registry, however it also affects all code doing lookups within that directory, so we must default it to off.

Create the handle in a way where i/o upon it can be multiplexed with other i/o on the same initiating thread of execution i.e. you can perform more than one read concurrently, without using threads. The blocking operations .read() and .write() may have to use a less efficient, but cancellable, blocking implementation for handles created in this way. On Microsoft Windows, this creates handles with OVERLAPPED semantics. On POSIX, this creates handles with nonblocking semantics for non-file handles such as pipes and sockets, however for file, directory and symlink handles it does not set nonblocking, as it is non-portable.

< Using insane POSIX byte range locks

< This is an inode created with no representation on the filing system

                                               {
   none = uint16_t(0),  //!< No flags
   /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed
   to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,
   if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous
   editions of Windows, the file entry does not disappears but becomes unavailable for
   anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the
   `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is
   somewhat emulated by LLFIO on older Windows by renaming the file to a random name on `close()`
   causing it to appear to have been unlinked immediately.
   */
   unlink_on_first_close = uint16_t(1U << 0U),
  
   /*! Some kernel caching modes have unhelpfully inconsistent behaviours
   in getting your data onto storage, so by default unless this flag is
   specified LLFIO adds extra fsyncs to the following operations for the
   caching modes specified below:
   * truncation of file length either explicitly or during file open.
   * closing of the handle either explicitly or in the destructor.
  
   Additionally on Linux only to prevent loss of file metadata:
   * On the parent directory whenever a file might have been created.
   * On the parent directory on file close.
  
   This only occurs for these kernel caching modes:
   * caching::none
   * caching::reads
   * caching::reads_and_metadata
   * caching::safety_barriers
   */
   disable_safety_barriers = uint16_t(1U << 2U),
   /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has
   renamed the open file handle since the time it was opened. To prevent this occuring,
   where the OS doesn't provide race free unlink-by-open-handle we compare the inode of
   the path we are about to unlink with that of the open handle before unlinking.
   \warning This does not prevent races where in between the time of checking the inode
   and executing the unlink a third party changes the item about to be unlinked. Only
   operating systems with a true race-free unlink syscall are race free.
   */
   disable_safety_unlinks = uint16_t(1U << 3U),
   /*! Ask the OS to disable prefetching of data. This can improve random
   i/o performance.
   */
   disable_prefetching = uint16_t(1U << 4U),
   /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file
   into kernel cache. This can improve sequential i/o performance.
   */
   maximum_prefetching = uint16_t(1U << 5U),
  
   win_disable_unlink_emulation = uint16_t(1U << 9U),  //!< See the documentation for `unlink_on_first_close`
   /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally
   implement extents-based storage and thus could only represent sparse files via
   efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),
   a proper extents-based on-storage representation was added, thus allowing only 64Kb
   extent chunks written to be stored irrespective of whatever the maximum file extent
   was set to.
  
   For various historical reasons, extents-based storage is disabled by default in newly
   created files on NTFS, unlike in almost every other major filing system. You have to
   explicitly "opt in" to extents-based storage.
  
   As extents-based storage is nearly cost free on NTFS, LLFIO by default opts in to
   extents-based storage for any empty file it creates. If you don't want this, you
   can specify this flag to prevent that happening.
   */
   win_disable_sparse_file_creation = uint16_t(1U << 10U),
   /*! Filesystems tend to be embarrassingly parallel for operations performed to different
   inodes. Where LLFIO performs i/o to multiple inodes at a time, it will use OpenMP or
   the Parallelism or Concurrency standard library extensions to usually complete the
   operation in constant rather than linear time. If you don't want this default, you can
   disable default using this flag.
   */
   disable_parallelism = uint16_t(1U << 11U),
   /*! Microsoft Windows NTFS has the option, when creating a directory, to set whether
   leafname lookup will be case sensitive. This is the only way of getting exact POSIX
   semantics on Windows without resorting to editing the system registry, however it also
   affects all code doing lookups within that directory, so we must default it to off.
   */
   win_create_case_sensitive_directory = uint16_t(1U << 12U),
  
   /*! Create the handle in a way where i/o upon it can be multiplexed with other i/o
   on the same initiating thread of execution i.e. you can perform more than one read
   concurrently, without using threads. The blocking operations `.read()` and `.write()`
   may have to use a less efficient, but cancellable, blocking implementation for handles created
   in this way. On Microsoft Windows, this creates handles with `OVERLAPPED` semantics.
   On POSIX, this creates handles with nonblocking semantics for non-file handles such
   as pipes and sockets, however for file, directory and symlink handles it does not set
   nonblocking, as it is non-portable.
   */
   multiplexable = uint16_t(1U << 13U),
  
   // NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!
  
   byte_lock_insanity = uint16_t(1U << 14U),  //!< Using insane POSIX byte range locks
   anonymous_inode = uint16_t(1U << 15U)      //!< This is an inode created with no representation on the filing system
   } QUICKCPPLIB_BITFIELD_END(flag)

◆ set_append_only()

virtual result<void> llfio_v2_xxx::handle::set_append_only ( bool enable )

inlinevirtualnoexceptinherited

EXTENSION: Changes whether this handle is append only or not.

Warning: On Windows this is implemented as a bit of a hack to make it fast like on POSIX, so make sure you open the handle for read/write originally. Note unlike on POSIX the append_only disposition will be the only one toggled, seekable and readable will remain turned on.

Errors returnable\n Whatever POSIX fcntl() returns. On Windows nothing is changed on the handle.

Memory Allocations\n No memory allocation.

Reimplemented in llfio_v2_xxx::process_handle.

The documentation for this class was generated from the following files:

include/llfio/v2.0/byte_io_multiplexer.hpp
include/llfio/v2.0/byte_io_handle.hpp

Classes

Public Types

Public Member Functions

Static Protected Member Functions

Protected Attributes

Static Protected Attributes

Detailed Description

Member Enumeration Documentation

◆ barrier_kind

Member Function Documentation

◆ clone()

◆ current_path()

◆ do_byte_io_handle_register() [1/2]

◆ do_byte_io_handle_register() [2/2]

◆ handle() [1/4]

◆ handle() [2/4]

◆ handle() [3/4]

◆ handle() [4/4]

◆ QUICKCPPLIB_BITFIELD_BEGIN_T()

◆ set_append_only()