What means "immediately" in seastar:;connected_socket shutdowns?

[kelbon]

shutdown_input / shutdown_output comment says:

    /// Disables output to the socket.
    ///
    /// Current or future writes that have not been successfully flushed
    /// will immediately fail with an error.  This is useful to abort
    /// operations on a socket that is not making progress due to a
    /// peer failure.
    void shutdown_output();
    /// Disables input from the socket.
    ///
    /// Current or future reads will immediately fail with an error.
    /// This is useful to abort operations on a socket that is not making
    /// progress due to a peer failure.
    void shutdown_input();

What means immediately here? Is it invoking future with error like boost::asio socket do,. or pushing some task to some queue and it will be called in future? How debug task reordering and preempting may be involved here?

[tgrabiec]

Is it invoking future with error like boost::asio socket do,. or pushing some task to some queue and it will be called in future?

The futures associated with blocked calls will be failed immediately, meaning after the call returns, the future is failed. It will be failed with an exception (that's the only way to fail a future).

If those futures have callbacks on them, they will be executed at unspecified time later, depending on CPU load. The seastar framework never invokes callbacks on blocked futures synchronously with wakeup context (shutdown_output() here), they are scheduled for execution as separate tasks, according to the scheduler's logic.

[kelbon]

Is it invoking future with error like boost::asio socket do,. or pushing some task to some queue and it will be called in future?

The futures associated with blocked calls will be failed immediately, meaning after the call returns, the future is failed. It will be failed with an exception (that's the only way to fail a future).

If those futures have callbacks on them, they will be executed at unspecified time later, depending on CPU load. The seastar framework never invokes callbacks on blocked futures synchronously with wakeup context (shutdown_output() here), they are scheduled for execution as separate tasks, according to the scheduler's logic.

Thank you for answer.

Lets see. I want my future to stop all readers and all writers for socket, i wrote such code:

future<> f() {
// push writers/readers into current shard queue
...shutdown_input()l
...shutdown_output();
// goint to end of current queue
co_await seastar::yield();
// here i must have guarantee, that all writers/readers received exceptions

}

But as i know, seastar reorders tasks in queue, so my code will not work. How to disable such seastar behavior?

[kelbon]

@tgrabiec which exception will be thrown when operation cancelled by shutdown input/output? Where it is written?

[tgrabiec]

The standard way to synchronize with other fibers is to use seastar::gate, you enter the gate in other processes using with_gate(), and call co_await gate::close() in the fiber which wants to wait for the other fibers to finish after a signal.

Or just wait on the future representing the connection handler if it's a single fiber. See how it's done in memcache.cc

Relying on task execution order is not a good approach because order is not guaranteed, and even if it was, it's racy - a send() attempt can be queued from a task which executes after you call yield(). If you need to synchronize with fibers, use future/promise or higher-level synchronization primitives like a gate.

How to disable such seastar behavior?

There is no way to disable it, it's by design.