это третий пул что ли?((

Да.
В отличии от шедулинга, он настраивается как раз как пул. А шедулер настраивается не так же, как остальные пулы в акке.

Мне кажется это сорт диспетчера, который подтягивается, так же как и акка хттпшный, расширениями

FileIO - часть базовый стримов, если мы о них говорим. В нем используется akka.stream.materializer.blocking-io-dispatcher, который, если мне не изменяет память, ссылается на akka.actor.default-blocking-io-dispatcher. Возможно он лениво инициализируется, но все же его стоит считать стандартным пулом для блокирующих операций в akka.
Вообще этим стандартные пулы в акке не исчерпываются. Если покапать, то там еще есть как минимум akka.io.pinned-dispatcher

Но он уже для сильно специфичных операций.

Ну судя по всему - да, вся суть этой опции, что она переопределяет атрибут Dispatcher для текущего актора, если он там уже не переопределён.
Т.е. вряд ли можно ожидать, что этот пул вообще будет инициализирован до того, как хотя бы одна операция из FileIO материализуется

а в акка стримах при броадкастинге обработка элементов стекающих в один output-порт отработает асинхронно от обработки ведущей к другому output-порту?

или сначала в первый порт, потом во второй и тд?

зависит от того, как описан стрим
а именно: надо смотреть Backpressures when каждого использованного шага

val writeAuthors: Sink[Author, NotUsed] = ???
val writeHashtags: Sink[Hashtag, NotUsed] = ???
val g = RunnableGraph.fromGraph(GraphDSL.create() { implicit b =>
 import GraphDSL.Implicits._

 val bcast = b.add(Broadcast[Tweet](2))
 tweets ~> bcast.in
 bcast.out(0) ~> Flow[Tweet].map(_.author) ~> writeAuthors
 bcast.out(1) ~> Flow[Tweet].mapConcat(_.hashtags.toList) ~> writeHashtags
 ClosedShape
})
g.run()

тут их явно не задано, например

работают параллельно, но получают события одновременно

один ждёт другого что ли?если тот раньше

Broadcast:

Backpressures when any of the outputs backpressure

а все все. сорри. получают же именно события одновременно

спасибо

То есть бродкаст примет следующий элемент только когда обе ветки будут готовы принять его

но обрабатывается каждый элемент параллельно

да, понятно

Кстати, это можно написать без Graph DSL

И я не уверен, что код выше корректен относительно Graph DSL - не стоит принимать так внешние синки

в этом наверное и есть смысл использования броадкастинга.

потому что я хотел спросить почему бы просто не описать два линейных графа под такую задачу. если все равно хотим две асинхронные обработки организовать