consistency issues with the handling of stop requests in `split` and `ensure_started`

[ericniebler]

@lewissbaker writes:

At the moment, with ensure_started() if a stop request is issued before start() is called, then if the operation has not yet completed we basically just detach, request-cancellation of the child operation and then complete synchronously with set_stopped().

However, if we send a stop-request just after start() returns, then the stop-request is sent to the child operation and we wait for it to complete before signalling completion.

Similarly for split(), if the first consumer to connect/start the operation happens to have a stop-request already issued then it immediately completes with set_stopped and does not start the operation. However, a second consumer of split() that does not yet have a stop-request on entry to start() will then start the underlying operation and, if a stop-request subsequently comes, will stop the child operation for all consumers. In this case, some consumers may see different results from other consumers.

This seems inconsistent. I think perhaps that if you connect/start the split/ensure_started sender then it should always wait for the underlying operation to complete. If the first consumer of split() to start the operation has an outstanding stop-request then perhaps it should mark the underlying operation as stopped for all subsequent consumers? Or alternatively, just start the underlying operation and let it handle completing synchronously and then notifying all registered consumers...

[lewissbaker]

Closing as duplicate.

This issue should be addressed with #263 (which redefines the semantics of split()).

Note that ensure_started has been removed and is no longer relevant.