JosiahWI commented on code in PR #13881:
URL: https://github.com/apache/trafficserver/pull/13881#discussion_r4339096575
##########
include/iocore/eventsystem/Action.h:
##########
@@ -89,6 +93,48 @@ class Action
*/
bool cancelled = false;
+ /**
+ Calls back @c continuation for this operation unless the operation has
+ been cancelled.
+
+ @param[in] event The event code passed to the handler.
+ @param[in] data The data passed to the handler.
+
+ @return Returns the handler's return value, or an empty optional if
+ the operation has been cancelled.
+
+ @pre If the operation has not been cancelled, @c continuation points
+ to a live Continuation with a handler installed, and
+ @c continuation->mutex and @c mutex are both null or refer to
+ the same mutex.
+
+ @note The handler may destroy @c continuation and this Action. Unless
+ the owner documents otherwise, do not access either after this
+ call returns.
+
+ @note If @p data transfers ownership of an object to @c continuation,
+ the caller must dispose of that object when the result is empty.
+
+ @par Thread Safety
+ Not thread-safe. The caller must hold @c mutex where non-null.
+ */
+ std::optional<int>
+ call_back(int event, void *data)
+ {
+ ink_release_assert((!this->mutex || this_ethread() ==
this->mutex->thread_holding) &&
+ "action mutex not held by calling thread");
+
+ // Cancellation check happens before remaining precondition checks
+ // because the continuation must not be accessed if it is cancelled.
+ if (this->cancelled) {
+ return {};
+ }
+
+ ink_release_assert(this->continuation->mutex == this->mutex && "action and
continuation mutex mismatch");
+ ink_release_assert(!this->continuation->handler.is<nullptr>() && "callback
to null handler");
+ return this->continuation->handleEvent(event, data);
+ }
Review Comment:
If we want to avoid an abort in this scenario, then the correct fix is to
refuse to perform the callback and log a debug message. But again, the
consequences advise against this approach: what should a caller do if its
action is implicitly cancelled due to a corrupted action state? There is no
sure way to fix the problem and retry the callback, so in the best case
scenario this would lead to sending 5xx responses back to the client, and if
the failure is due to a memory corruption caused by another bug, the server may
effectively be down even though we didn't abort it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
