The __inplace_stop_callback_base structure is defined as follows:
struct __inplace_stop_callback_base {
const inplace_stop_source* __source_;
__execute_fn_t* __execute_;
__inplace_stop_callback_base* __next_ = nullptr;
__inplace_stop_callback_base** __prev_ptr_ = nullptr;
bool* __removed_during_callback_ = nullptr;
std::atomic<bool> __callback_completed_{false};
};
However, it's worth noting that there are two distinct phases of use of this data-structure:
- The callback is inserted in the linked-list of items, waiting to be executed
- The callback is actually being executed and needs synchronisation regarding the completion of the callback.
The data-members __removed_during_callback_ and __callback_completed_ are only ever used in the second phase and the data-members __next_ and __prev_ptr_ are only ever used in the first phase.
This means that these data-members can be placed into a union so that the storage for the next/prev pointers is reused for the removed/completed data-members during the second phase. Doing so would shrink the size of the __inplace_stop_callback_base structure from 6 pointers (48 bytes on 64-bit machines) to 4 pointers (32 bytes on 64-bit machines).
For example:
struct __inplace_stop_callback_base {
const inplace_stop_source* __source_;
__execute_fn_t* __execute_;
struct __list_members_t {
__inplace_stop_callback_base* __next_ = nullptr;
__inplace_stop_callback_base** __prev_ptr_ = nullptr;
};
struct __execute_members_t {
bool* __removed_during_callback_ = nullptr;
std::atomic<bool> __callback_completed_{false};
};
union {
__list_members_t __list_members_;
__execute_members_t __execute_members_;
};
};
The __execute_ data-member can be used as a discriminator to determine which data-members are active. The __execute_ member contains the function pointer that will be invoked and needs to be populated while the callback is sitting in the queue of callbacks to be invoked. However, we could set this data-member to nullptr when the function is being executed - we can take a copy of the function-pointer into a local variable inside inplace_stop_source::request_stop() and then set the __execute_ data-member to nullptr before initializing the __removed_during_callback_ and __callback_completed_ members. The __execute_ data-member can then be used by the callback deregistration to determine whether the callback is still a member of the list or has been or is in the process of being executed.
The
__inplace_stop_callback_basestructure is defined as follows:However, it's worth noting that there are two distinct phases of use of this data-structure:
The data-members
__removed_during_callback_and__callback_completed_are only ever used in the second phase and the data-members__next_and__prev_ptr_are only ever used in the first phase.This means that these data-members can be placed into a union so that the storage for the next/prev pointers is reused for the removed/completed data-members during the second phase. Doing so would shrink the size of the
__inplace_stop_callback_basestructure from 6 pointers (48 bytes on 64-bit machines) to 4 pointers (32 bytes on 64-bit machines).For example:
The
__execute_data-member can be used as a discriminator to determine which data-members are active. The__execute_member contains the function pointer that will be invoked and needs to be populated while the callback is sitting in the queue of callbacks to be invoked. However, we could set this data-member tonullptrwhen the function is being executed - we can take a copy of the function-pointer into a local variable insideinplace_stop_source::request_stop()and then set the__execute_data-member tonullptrbefore initializing the__removed_during_callback_and__callback_completed_members. The__execute_data-member can then be used by the callback deregistration to determine whether the callback is still a member of the list or has been or is in the process of being executed.