Namespaces
Variants
Views
Actions

Difference between revisions of "cpp/execution/ensure started"

From cppreference.com
< cpp‎ | execution
m (Reverted edits by Cooky (talk) to last revision by InbalL)
m (-"std::" to follow the style, though this facility was dropped indeed.)
 
(One intermediate revision by one user not shown)
Line 1: Line 1:
 
{{cpp/execution/title|ensure_started}}
 
{{cpp/execution/title|ensure_started}}
{{cpp/experimental/execution/navbar}}
+
{{cpp/execution/navbar}}
  
 
{{fmbox|class=noprint|style=font-size: 0.8em|text='''Note''' This utility is planned to be dropped from P2300 and replaced by {{tt|async_scope}}.}}
 
{{fmbox|class=noprint|style=font-size: 0.8em|text='''Note''' This utility is planned to be dropped from P2300 and replaced by {{tt|async_scope}}.}}
  
 
{{ddcl|header=execution|since=c++26|
 
{{ddcl|header=execution|since=c++26|
execution::sender auto ensure_started(
+
execution::sender auto ensure_started( execution::sender auto sender );
    execution::sender auto sender
+
);
+
 
}}
 
}}
  
Line 21: Line 19:
 
* Once {{tt|ensure_started}} returns, it is known that the provided {{c|sender}} has been connected and start has been called on the resulting operation state. In other words, the work described by the provided {{c|sender}} has been submitted for execution on the appropriate execution resources.
 
* Once {{tt|ensure_started}} returns, it is known that the provided {{c|sender}} has been connected and start has been called on the resulting operation state. In other words, the work described by the provided {{c|sender}} has been submitted for execution on the appropriate execution resources.
  
* If the returned sender is destroyed before {{c|execution::connect()}} is called, or if {{c|execution::connect()}} is called but the returned operation-state is destroyed before {{c|execution::start()}} is called, then a stop-request is sent to the eagerly launched operation and the operation is detached and will run to completion in the background.  
+
* If the returned sender is destroyed before {{lc|execution::connect()}} is called, or if {{lc|execution::connect()}} is called but the returned operation-state is destroyed before {{lc|execution::start()}} is called, then a stop-request is sent to the eagerly launched operation and the operation is detached and will run to completion in the background.  
  
 
* In such a case, the operation's result will be discarded when it is eventually complete.
 
* In such a case, the operation's result will be discarded when it is eventually complete.
  
 
* Note that the application will need to make sure that resources are kept alive in the case that the operation detaches (e.g. by holding a {{lc|std::shared_ptr}} to those resources).
 
* Note that the application will need to make sure that resources are kept alive in the case that the operation detaches (e.g. by holding a {{lc|std::shared_ptr}} to those resources).

Latest revision as of 12:11, 4 October 2024

 
 
 
Defined in header <execution>
execution::sender auto ensure_started( execution::sender auto sender );
(since C++26)

[edit] Parameters

sender - input sender of which the stopped channel is mapped into err

[edit] Return value

Returns a sender which completes when the provided sender completes and sends values equivalent to those of the provided sender.

[edit] Notes

  • Once ensure_started returns, it is known that the provided sender has been connected and start has been called on the resulting operation state. In other words, the work described by the provided sender has been submitted for execution on the appropriate execution resources.
  • If the returned sender is destroyed before execution::connect() is called, or if execution::connect() is called but the returned operation-state is destroyed before execution::start() is called, then a stop-request is sent to the eagerly launched operation and the operation is detached and will run to completion in the background.
  • In such a case, the operation's result will be discarded when it is eventually complete.
  • Note that the application will need to make sure that resources are kept alive in the case that the operation detaches (e.g. by holding a std::shared_ptr to those resources).