Ваш generate_buffer() NIF создает поток для вызова generate_binary(), но вызывающий NIF не ожидает завершения создания нового потока.Поток только что создан и, вероятно, все еще работает к моменту возврата NIF, хотя это будет недетерминировано, поскольку потоки в целом.Вы, вероятно, разбиваете эмулятор Erlang BEAM, потому что generate_binary() отключен, пытаясь вызвать систему исполнения Erlang после возвращения generate_buffer(), ужасно путая бедняжку.
Теперь, даже если вы исправитечтобы сделать то, что вы хотели, я не думаю, что вам вообще следует использовать явные нативные потоки.
Во-первых, Erlang NIF должны выглядеть как обычные функции Erlang, отличающиеся только тем, что они происходятбыть написанным на другом языке.Функции Erlang не порождают отдельные потоки выполнения, затем возвращаются, оставляя этот поток работающим.За исключением тех, которые имеют дело с вводом-выводом и постоянным хранением данных, функции Erlang являются детерминированными и относительно прозрачными .Ваш NIF не является ни тем, ни другим.Таким образом, даже если это сработало, это все еще «неправильно» в том смысле, что оно нарушает ожидания опытного программиста на Erlang.
Во-вторых, если вам нужна многопроцессорная обработка, Erlang уже дает представление о процессах.Если ваш NIF действительно проделает так много работы, что может извлечь выгоду из многопроцессорности, почему бы не переработать ваш NIF, чтобы он мог работать с поддиапазоном данных, а затем вызывать его несколько раз, по одному из нескольких процессов Erlang?Тогда вам не нужны явные нативные потоки;эмулятор BEAM создаст оптимальное для вас оптимальное количество потоков.
В-третьих, накладные расходы на создание потоков приведут к снижению производительности, если время жизни потока будет продолжаться только в течение одного вызова Erlang NIF, так каккажется, вы на самом деле намеревались.Это еще одна причина, по которой процессы Эрланга будут более эффективными.