Su generate_buffer() NIF está creando un hilo para llamar al generate_binary() pero el NIF llamante no espera a que termine el subproceso recién creado. El subproceso acaba de crearse y es probable que siga ejecutándose cuando vuelva el NIF, aunque esto no será determinista, ya que los hilos son en general. Probablemente esté bloqueando el emulador Erlang BEAM porque generate_binary() está apagado al tratar de llamar al sistema de tiempo de ejecución de Erlang después de que generate_buffer() ha vuelto, confundiendo al pobre de forma horrible.
Ahora, incluso suponiendo que corrija esto para que haga lo que quería, no creo que deba utilizar hilos nativos explícitos aquí en absoluto.
En primer lugar, se supone que las NIF de Erlang se parecen a las funciones de Erlang normales, y solo difieren en que están escritas en un idioma diferente. Las funciones de Erlang no generan hilos de ejecución separados, luego regresan, dejando ese hilo ejecutándose. Exceptuando aquellos que se ocupan de E/S y almacenamiento persistente de datos, las funciones de Erlang son deterministas y referentially transparent. Tu NIF no es ninguna de las dos cosas. Por lo tanto, incluso si funcionó, sigue siendo "incorrecto" en el sentido de que viola las expectativas de un experimentado programador de Erlang.
En segundo lugar, si necesita multiprocesamiento, Erlang ya proporciona la idea de los procesos. Si su NIF realmente hace tanto trabajo que puede beneficiarse del multiprocesamiento, ¿por qué no reelaborar su NIF para que funcione en un subrango de los datos, y luego llamarlo varias veces, una vez cada uno de una serie de procesos de Erlang? Entonces no necesitas hilos nativos explícitos; el emulador BEAM creará la cantidad óptima de hilos para usted, de forma transparente.
En tercer lugar, la sobrecarga de creación de subprocesos va a matar el rendimiento si la duración del subproceso solo se extiende en el transcurso de una sola llamada Erlang NIF, como parece que realmente pretendía. Esta es otra razón por la cual los procesos de Erlang serán más eficientes aquí.