morph 0.1.0
Asynchronous bridge between GUI thread and business models
Loading...
Searching...
No Matches
morph::tui::LoopExecutor Class Referencefinal

Runs every posted task in a later turn of one core::net::EventLoop, with this executor current. More...

#include <loop_executor.hpp>

Inheritance diagram for morph::tui::LoopExecutor:
morph::exec::IExecutor

Public Member Functions

 LoopExecutor (::core::net::EventLoop &loop)
 ~LoopExecutor () override
 Destroys the executor; tasks it posted that have not run yet are dropped when the loop reaches them.
 LoopExecutor (LoopExecutor const &)=delete
LoopExecutor & operator= (LoopExecutor const &)=delete
 LoopExecutor (LoopExecutor &&)=delete
LoopExecutor & operator= (LoopExecutor &&)=delete
void post (std::function< void()> task) override
 Queues task for a later turn of the loop.
Public Member Functions inherited from morph::exec::IExecutor
 IExecutor (const IExecutor &)=delete
IExecutor & operator= (const IExecutor &)=delete
 IExecutor (IExecutor &&)=delete
IExecutor & operator= (IExecutor &&)=delete
virtual bool isSerial () const noexcept
 Whether this executor runs one task at a time, each after the tasks posted before it: a strand, a GUI loop, a pumped MainThreadExecutor.
::core::async::IExecutor & coreExecutor () noexcept
 This executor as a core-cpp executor: the identity an core::async::ExecutorScope names.

Detailed Description

Runs every posted task in a later turn of one core::net::EventLoop, with this executor current.

The TUI frontend's reactive Runtime is owned by one, and every BridgeHandler an application builds receives it as its callback executor, so model replies, timers, sockets and input all run on the thread that turns the loop. post() may be called from any thread. A task still queued when the executor is destroyed is dropped, and a task that throws is logged and does not stop the loop.

Destroy it on the thread that turns the loop, between turns or from inside one of its own tasks, never from another thread: a task already running there would go on using an owner (the reactive Runtime) that is gone. Nothing guards against that, because a lock held across a task would deadlock a task that destroys its own executor.

Definition at line 29 of file loop_executor.hpp.

Constructor & Destructor Documentation

◆ LoopExecutor()

morph::tui::LoopExecutor::LoopExecutor ( ::core::net::EventLoop & loop)
explicit
Parameters
loopThe loop to post to. Borrowed: it must outlive this executor.

Member Function Documentation

◆ post()

void morph::tui::LoopExecutor::post ( std::function< void()> task)
overridevirtual

Queues task for a later turn of the loop.

Parameters
taskWhat to run; inside it exec::runningOn(*this) holds.

Implements morph::exec::IExecutor.


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