Caso de uso de scala.concurrent.blocking

1. Los nuevos subprocesos se generan en el grupo fork / join cuando detecta que todos los subprocesos en el grupo fork / join están esperando el uno al otro utilizando la construcción de join , y hay más trabajo por completar que podría potencialmente terminar uno de los subprocesos . Alternativamente, si uno de los subprocesos de ForkJoinWorker está ejecutando código que bloquea de otra forma que no sea usando join , puede notificar al grupo utilizando ManagedBlocker .
2. Es potencialmente aplicable a cualquier tipo de contextos de ejecución: sirve como una notificación a la implementación ExecutionContext que el código ejecutado por un hilo de trabajo está bloqueando potencialmente en alguna condición, y que esta condición podría resolverse mediante el cálculo de otra cosa utilizando algún otro hilo. El contexto de ejecución puede o no actuar sobre esto. En la implementación actual (2.10, 2.11), el blocking solo funcionará con el contexto de ejecución global predeterminado.
3. Si ajusta cualquier ejecutable con locking, inducirá un poco de sobrecarga de tiempo de ejecución, por lo que no siempre lo haga.
4. Si tiene un cálculo que dura mucho tiempo, por ejemplo, segundos o minutos, o está esperando que un futuro lo complete con Await , o está esperando que la condición del monitor se resuelva, y esta condición puede resolverse mediante otra tarea / futuro que debe ejecutarse en el mismo contexto de ejecución: en todos estos casos, debe usar el blocking .

EDITAR:

Considere echar un vistazo al Capítulo 4 en el Progtwig de Aprendizaje Simultáneo en Scala .

Siempre encontré la documentación oficial un poco pobre con respecto a la construcción de locking; por lo tanto, traté de explicarlo más claramente en esta publicación de blog con ejemplos de cómo podría implementar la suya y cómo funciona bajo el capó.