Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tunnel requested abort exception to semaphore wait caller #2601

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

bhalevy
Copy link
Member

@bhalevy bhalevy commented Dec 26, 2024

Today, when calling wait(abort_source&) the caller always gets semaphore_aborted error when abort is requested.
However, with abort_on_expiry, the actual reason could be timeout expiry, which should be distinguishable from the abort error.

This series modifies abort_on_expiry first to request abort with a timed_out_error exception, and then internal::abortable_fifo and semaphore are changed to tunnel that exception to the caller.

Respective unit tests were added to test those cases.

The motivation for this change is scylladb/scylladb#22017
which will use scylladb utils::composite_abort_source to compose an abort_on_expiry abort_source, used for point request timeout and a global abort_source used on shutdown.

@bhalevy
Copy link
Member Author

bhalevy commented Dec 27, 2024

@scylladb/seastar-maint please review and consider merging

});
as.request_abort_ex(std::runtime_error("expected"));
sem.signal();
BOOST_CHECK_THROW(fut1.get(), std::runtime_error);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How confident are we, that this thrown-and-caught runtime_exception is the one from above as.request_abort_ex(), but not some "generic" runtime error that accidentally crept in along the way?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no reason to suspect that, but I can change this to a unique exception type to increase the confidence.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, please

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done in v2

So that users can distinguish between timer expiration
to other abort sources.

Signed-off-by: Benny Halevy <[email protected]>
For passing an exception_ptr from the abort_source
to the callback, allow the OnAbort class to have
a call operator accepting an optional exception_ptr.

Signed-off-by: Benny Halevy <[email protected]>
If waiting with timeout or abort_source, check (under [[unlikely]])
if the timeout is already expired, or abort requested, before
appending an entry to the wait_list, which is rather expensive.

We do this so that we can easily distinguish between timeout
error to aborted errors, as in `make_back_abortable` there
isn't a good way to distingush the two if abort is already
requested by the type-erased abort_source.

Signed-off-by: Benny Halevy <[email protected]>
Move into tests/unit/expected_exception.hh

Signed-off-by: Benny Halevy <[email protected]>
Accept an optional exception_ptr in the expiry_handler
and pass it on to the entry promise, so that the original
abort exception can be passed to the user.

This way we can distinguish between, e.g. timed_out_error
and abort_requested_error.

Signed-off-by: Benny Halevy <[email protected]>
@bhalevy bhalevy force-pushed the abort_on_expiry-timeout-error branch from a0e5507 to f8c36db Compare January 9, 2025 10:28
@bhalevy
Copy link
Member Author

bhalevy commented Jan 9, 2025

In v2 (f8c36db):

  • rebased
  • tests: unit: refactor expected_exception
  • used expected_exception in new semaphore unit test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants