folly::InlineExecutor — 호출자 thread에서 즉시 실행

한 줄 요약: InlineExecutor는 add(fn)을 그 자리에서 호출한다. 가장 단순한 Executor지만 동시에 가장 잘못 쓰이는 Executor다.

#동기 — Executor가 없는 Executor

folly::Executor는 추상 인터페이스다.

1
class Executor {
2
 public:
3
  virtual void add(Func) = 0;
4
  virtual uint8_t getNumPriorities() const { return 1; }
5
};

이 인터페이스를 가장 단순하게 구현하면 다음과 같다.

1
class InlineExecutor : public Executor {
2
 public:
3
  void add(Func f) override { f(); }
4
};

callback을 schedule하지 않고 호출자 thread에서 그대로 실행한다. 비동기성을 없애는 Executor다.

#Executor 4가지 모델 비교

Inline은 4가지 흔한 executor 모델 중 가장 단순한 끝에 있다.

Inline → Queued (single worker) → Fixed pool → Work-stealing 순으로 동시성과 복잡도가 올라간다. Inline은 0 오버헤드지만 deadlock과 stack overflow 위험이 있고, work-stealing은 로드밸런싱이 좋지만 cross-thread 동기화 비용이 든다.

#사용 사례

#1. 단위 테스트

1
TEST(MyFuture, ChainExecution) {
2
  auto sf = compute()
3
    .deferValue([](int x) { return x + 1; })
4
    .deferValue([](int x) { return x * 2; });
5

6
  // 테스트 thread에서 모든 callback이 동기적으로 실행됨
7
  auto v = std::move(sf).via(&folly::InlineExecutor::instance()).get();
8
  EXPECT_EQ(v, 86);
9
}

테스트는 결정적이어야 한다. InlineExecutor는 callback이 언제, 어디서 실행되는지 보장하므로 race가 없다.

#2. 이미 결정된 값의 단축 경로

1
folly::SemiFuture<Cache> getCachedOr(int id) {
2
  if (auto c = cache.find(id)) {
3
    return folly::makeSemiFuture(*c);   // 동기 결과
4
  }
5
  return fetchAsync(id);
6
}
7

8
// caller
9
getCachedOr(id)
10
  .via(&folly::InlineExecutor::instance())   // cache hit이면 inline
11
  .thenValue([](Cache c) { return process(c); });

cache hit일 때 thread switch 없이 바로 처리한다. cache miss라면 fetchAsync가 적절한 executor를 내부적으로 사용한다.

#3. SemiFuture를 강제로 명시적으로 inline 실행

1
auto v = computeSemi().via(&folly::InlineExecutor::instance()).get();

.via(executor)가 빠진 채 .get()을 부르면 내부적으로 InlineExecutor가 쓰인다. 의도가 inline이면 명시적으로 적는 게 코드 리뷰에 좋다.

#구현 — folly::InlineExecutor

1
namespace folly {
2

3
class InlineExecutor : public Executor {
4
 public:
5
  static InlineExecutor& instance() {
6
    static InlineExecutor x;
7
    return x;
8
  }
9

10
  void add(Func f) override {
11
    f();
12
  }
13
};
14

15
}  // namespace folly

코드가 10줄도 안 된다. singleton으로 노출되며 어디서든 folly::InlineExecutor::instance()로 접근한다.

#변형 — InlineLikeExecutor / QueuedImmediateExecutor

1
class QueuedImmediateExecutor : public Executor {
2
 public:
3
  void add(Func f) override {
4
    if (q_.empty()) {
5
      q_.push(std::move(f));
6
      while (!q_.empty()) {
7
        q_.front()();
8
        q_.pop();
9
      }
10
    } else {
11
      q_.push(std::move(f));
12
    }
13
  }
14
 private:
15
  static thread_local std::queue<Func> q_;
16
};

QueuedImmediateExecutor는 재진입을 막는다. callback A가 실행 중 callback B를 add하면 InlineExecutor는 B를 A 중간에 실행해 stack을 쌓는다. QueuedImmediateExecutor는 B를 큐에 넣어 A가 끝난 뒤 실행한다.

1
// 위험 — InlineExecutor
2
folly::Promise<int> p;
3
folly::InlineExecutor::instance().add([&] {
4
  p.setValue(1);   // 또 다른 callback을 즉시 실행 — stack 깊어짐
5
});
6

7
// 안전 — QueuedImmediateExecutor
8
folly::QueuedImmediateExecutor::instance().add([&] {
9
  p.setValue(1);   // queue에 들어가서 현재 callback 끝난 뒤 실행
10
});

긴 Future 체인에서는 QueuedImmediateExecutor가 stack overflow를 막는다.

#위험 — 잘못 쓰일 때

#1. 의도 없이 사용 (가장 흔함)

1
auto v = computeSemi().get();   // 내부적으로 InlineExecutor

compute()가 어디서 도는지 코드에서 보이지 않는다. 어떤 thread의 어떤 lambda 안인지 추적 불가.

#2. Stack overflow

1
folly::Future<int> f = ...;
2
for (int i = 0; i < 100'000; ++i) {
3
  f = std::move(f).via(&folly::InlineExecutor::instance())
4
                   .thenValue([](int x) { return x + 1; });
5
}
6
f.get();   // stack overflow 가능

각 thenValue가 즉시 다음 thenValue를 호출하므로 callback이 nested된다. 1만~10만 단위에서 stack 한계를 넘는다. QueuedImmediateExecutor가 해결책이다.

#3. Latency hiding

1
folly::SemiFuture<Result> handleRequest(Request req) {
2
  return validate(req)
3
    .via(&folly::InlineExecutor::instance())   // bad
4
    .thenValue([](auto r) { return process(r); });
5
}

caller가 RPC handler thread에서 handleRequest를 부르면 모든 callback이 그 thread에서 실행된다. 다른 요청이 starve된다.

#코드 리뷰 포인트

• .via(&InlineExecutor::instance()) 또는 .get() 직접 호출에 이유가 있는가? 없으면 적절한 executor로 바꾼다.
• Future 체인이 깊은가? InlineExecutor 대신 QueuedImmediateExecutor를 고려한다.
• 테스트에서만 InlineExecutor를 쓰는가? production code path와 분리한다.
• SemiFuture가 항상 즉시 완료되는가? 그렇다면 InlineExecutor가 안전하다.

#자주 보는 안티패턴

1
// 1. production hot path에서 .get() 호출
2
folly::SemiFuture<R> handleRpc(Req r) {
3
  auto v = doInternal(r).get();   // RPC thread block
4
  return processFurther(v);
5
}
6

7
// 2. 긴 체인을 InlineExecutor로
8
auto f = base;
9
for (auto& step : steps) {
10
  f = std::move(f).via(&inline).thenValue(step);   // stack 폭발 위험
11
}
12

13
// 3. shared executor를 쓰지 않는 이유로 InlineExecutor
14
// 그냥 적절한 thread pool을 만들어라
15

16
// 4. InlineExecutor를 명시 없이 사용
17
sf.thenValue(...)   // SemiFuture에는 .thenValue 없음 — 컴파일 에러
18
sf.via(...).thenValue(...)   // executor 명시

#std::execution과 비교

P2300의 std::execution::inline_scheduler(가칭)도 같은 의미다. 호출자 thread에서 즉시 실행한다. 사용 가이드라인도 비슷할 것이다.

#정리

• InlineExecutor는 callback을 caller thread에서 즉시 실행하는 가장 단순한 Executor다.
• 테스트, 단축 경로, 명시적 inline 표현에 적합하다.
• 의도 없이 사용하면 어디서 callback이 도는지 추적이 불가능하다.
• 긴 체인에서는 stack overflow 위험이 있다. QueuedImmediateExecutor를 사용한다.
• production handler에서는 거의 항상 부적합하다.
• .via(InlineExecutor)는 항상 의도를 적은 흔적이어야 한다.

#다음 편

Part 3-02: CPUThreadPoolExecutor에서 CPU-bound 작업을 위한 thread pool을 본다.

#관련 항목

• Folly Part 2-03 — SemiFuture vs Future
• Folly Part 3-04 — ManualExecutor — 결정적 테스트의 또 다른 길
• Folly Part 3-02 — CPUThreadPoolExecutor