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

Make it safe to shutdown a ThreadPoolTaskExecutor and backing NetworkInterfaceTL before starting it up

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 5.2 Required
    • Component/s: None
    • Operating System:
      ALL
    • Linked BF Score:
      38
    • Story Points:
      4

      Description

      If we call shutdown on a NetworkInterfaceTL before it starts up, we simply move kStopped into its _state member and do nothing else: see here

      void NetworkInterfaceTL::shutdown() {
          if (_state.swap(kStopped) != kStarted)
              return;
      

      This becomes a problem if startup is ever called on the same NetworkInterfaceTL before shutdown completes; we'll fail this invariant in startup here:

      void NetworkInterfaceTL::startup() {
          stdx::lock_guard<Latch> lk(_mutex);
       
          _ioThread = stdx::thread([this] {
              setThreadName(_instanceName);
              _run();
          });
       
          invariant(_state.swap(kStarted) == kDefault);
      }
      

      because the _state will will been kStopped, not kDefault, before this was called.

      This is also a problem for the shutdown of ThreadPoolTaskExecutors, as they wrap a NetworkInterfaceTL. On startup, these executors call startup on the backing NetworkInterfaceTL. And if join is called on such an executor, it will call shutdown on the underlying NetworkInterface. So if join is called before startup is on such an executor, we'll encounter the same invariant.

      Acceptance criteria: make the invariant an exception/investigate it thoroughly and ensure lifetime semantics of NetworkInterfaceTL is clear

        Attachments

          Activity

            People

            Assignee:
            backlog-server-servicearch Backlog - Service Architecture
            Reporter:
            george.wangensteen George Wangensteen
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: