Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-66261

Add a task executor that executes inline on the Future side

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 7.0.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Service Arch
    • Fully Compatible
    • Service Arch 2023-03-20, Service Arch 2023-04-03
    • 105

      It would be nice to have an executor compatible with ExecutorFutures that executes its tasks inline on the caller's thread so we can run code written to be async compatible synchronously (like QueuedImmediateExecutor from facebook/folly). This would be especially useful for the recently added TransactionWithRetries type, which executes transaction commands on a given executor but every current use is in a synchronous context.

      We already have the InlineQueuedCountingExecutor which seems to do this, but it's in a test file so is probably not production quality.


      The initial use case for this will be `SyncTransactionWithRetries::runNoThrow`, which currently runs a work on an executor while using `get` to cause the main thread to wait. In this situation, there is no reason for the work to be run on a different thread.

      This can be solved with a new type `ManuallyManagedExecutor`. 

      Before:

      Future fut = somethingThatTakesAnExecutor(_exec);
      fut.get(); // Blocking call if fut is not ready. Work is done on a thread owned by `_exec`.

      After:

      ManuallyManagedExecutor exec();
      Future fut = somethingThatTakesAnExecutor(exec);
      exec.runUntilReady(fut); // Work is done on this thread.
      fut.get(); // Not a blocking call because we know fut is ready.

      Note: There are complications associated with the existing usage patterns around executors. Generally executors are managed with shared_ptr. This means that a function taking this sort of executor might hold onto it longer than the caller expected. The correct implementation will need to take this into account and have some concept of an owner, so when the owner goes out of scope, it can reject work or maybe forward work to a fallback executor (otherwise accidental users of this executor will just hang).

            Assignee:
            amirsaman.memaripour@mongodb.com Amirsaman Memaripour
            Reporter:
            jack.mulrow@mongodb.com Jack Mulrow
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: