llfio_v2_xxx::byte_io_multiplexer::io_operation_state Struct Reference

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

#include "byte_io_multiplexer.hpp"

Inheritance diagram for llfio_v2_xxx::byte_io_multiplexer::io_operation_state:

Classes
struct	lock_guard
	Used by the visitor to control the state lock. More...

Public Member Functions
virtual void *	invoke (function_ptr< void *(io_operation_state_type)> c) const noexcept=0
	Invoke the callable with the per-i/o state lock held, if any.
virtual io_operation_state_type	current_state () const noexcept=0
	Used to retrieve the current state of the i/o operation.
virtual io_result< buffers_type >	get_completed_read () &&noexcept=0
	After an i/o operation has finished, can be used to retrieve the result if the visitor did not.
virtual io_result< const_buffers_type >	get_completed_write_or_barrier () &&noexcept=0
	After an i/o operation has finished, can be used to retrieve the result if the visitor did not.
virtual io_operation_state *	relocate_to (byte *to) noexcept=0
	Relocate the state to new storage, clearing the original state. Terminates the process if the state is in use.

Public Attributes
byte_io_handle *	h {nullptr}
	The i/o handle the i/o operation is upon.
io_operation_state_visitor *	visitor {nullptr}
	The state visitor supplied when the operation was initialised.

Protected Member Functions
constexpr	io_operation_state (byte_io_handle *_h, io_operation_state_visitor *_visitor)
virtual void	_lock () noexcept
virtual void	_unlock () noexcept

Friends
struct	lock_guard

Detailed Description

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

You will need to ask the i/o multiplexer for how much storage, and alignment, is required to store one of these using byte_io_multiplexer::io_state_requirements(). Be aware that for some i/o multiplexers, quite a lot of storage (e.g. > 1Kb for IOCP on Windows) may be required. You can either preallocate i/o operation states for later use, or use other determinism-maintaining tricks to avoid dynamic memory allocation for i/o operation states.

When you construct one of these using byte_io_multiplexer::init_io_operation(), you must pass in a pointer to a io_operation_state_visitor. This visitor will be called whenever the lifecycle for the i/o state is about to change (it is called just before .current_state() is changed, and with any per-state locks held).

The lifecycle for one of these is as follows:

1. i/o initialised. This is after byte_io_multiplexer::init_io_operation() has been called to initialise the i/o operation state. You can now no longer relocate the i/o operation state in memory until the corresponding *_finished() visitor function is called.
2. i/o initiated. One is notified of this by the call of the corresponding visitor *_initiated() function. This may occur in byte_io_multiplexer::init_io_operation(), in byte_io_multiplexer::flush_inited_io_operations(), or never at all if the i/o completed immediately.
3. When the i/o completes, one is notified of the i/o's result by the call of the corresponding *_completed() visitor function. This can occur at any time, and can be called by any kernel thread, if the i/o multiplexer in use is used by multiple kernel threads. The completion functions are usually invoked by somebody calling byte_io_multiplexer::check_io_operation() or byte_io_multiplexer::check_for_any_completed_io(), but may also be called by an asynchronous system agent.
4. The i/o operation state may still be in use by others. You must not relocate in memory the i/o operation state after byte_io_multiplexer::init_io_operation() returns until the corresponding *_finished() visitor function is called.

---

The documentation for this struct was generated from the following file:

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