Why we do journal complete entry response in journal-single-thread, but not in other thread

[TakaHiR07]

QUESTION

I am confused in this part of code. I add another metric to monitor the latency of complete entry pendingResponse. I simulate a little big entry throughput, make the journalSyncData config to false. Then you can see that not only bc.flush(), entry.run() and flushPendingResponse also need to consume some time.
This code is done at a single journal critical thread. Why we not move the complete response in another thread? Such as netty iothread or CommonPool

bookkeeper/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/Journal.java

Lines 1088 to 1116 in 2b5b992

	// toFlush is non null and not empty so should be safe to access getFirst
	if (shouldFlush) {
	if (journalFormatVersionToWrite >= JournalChannel.V5) {
	writePaddingBytes(logFile, paddingBuff, journalAlignmentSize);
	}
	journalFlushWatcher.reset().start();
	bc.flush();
	for (int i = 0; i < toFlush.size(); i++) {
	QueueEntry entry = toFlush.get(i);
	if (entry != null && (!syncData || entry.ackBeforeSync)) {
	toFlush.set(i, null);
	numEntriesToFlush--;
	if (entry.getCtx() instanceof BookieRequestHandler
	&& entry.entryId != BookieImpl.METAENTRY_ID_FORCE_LEDGER) {
	writeHandlers.add((BookieRequestHandler) entry.getCtx());
	}
	entry.run();
	}
	}
	writeHandlers.forEach(
	(ObjectProcedure<? super BookieRequestHandler>)
	BookieRequestHandler::flushPendingResponse);
	writeHandlers.clear();
	lastFlushPosition = bc.position();
	journalStats.getJournalFlushStats().registerSuccessfulEvent(
	journalFlushWatcher.stop().elapsed(TimeUnit.NANOSECONDS), TimeUnit.NANOSECONDS);

The new metric is added at here: