Erlang NIF线程未join致资源崩溃及相关技术疑问

我开发的项目中，有一个从主Erlang应用调用的NIF，需要借助OpenNN完成神经网络模型的计算与训练，因此通过新创建的Erlang NIF线程来执行相关逻辑。

原C代码片段：

.....
res = enif_thread_create((char*)"train_nif_proc", &(TrainNNptr->tid), trainFun, (void*) pTrainNNptr, 0);

if (res)
{
    LogError("failed to call enif_thread_create with trainFun");
    nifpp::str_atom ret_status("train_error");
    return nifpp::make(env, ret_status);
}
.....

这段代码在Raspbian Bullseye上运行时崩溃，报错信息为std::system_error: Resource temporarily unavailable。添加以下代码后，问题得到解决：

else
{
    res = enif_thread_join(TrainNNptr->tid, exit_code );
    if (res)
    {
        LogError("failed to join with trainFun");
        nifpp::str_atom ret_status("train_error");
        return nifpp::make(env, ret_status);
    }
}

根据enif_thread_create的文档说明：创建线程的驱动需在驱动卸载前通过erl_drv_thread_join完成线程join。

基于此，我有以下三个疑问：

1. NIF何时会被卸载？我的NIF在应用启动时加载，代码中从未主动卸载，为何仍需调用join？
2. 当调用NIF方法的进程因erl_drv_thread_join阻塞时，Erlang调度器会如何处理？
3. NIF函数的响应时长是否存在限制？

疑问解答 #

1. NIF卸载时机与join必要性
   NIF的卸载场景不止主动调用这一种：

• 当Erlang节点关闭时，所有加载的NIF都会被系统自动卸载；
• 如果NIF所属的应用被停止（比如调用application:stop/1），对应的NIF也会被卸载；
• 更关键的是，即使你没主动触发卸载，反复创建线程却不join会导致系统线程资源耗尽——这正是你在Raspbian上崩溃的直接原因。未join的线程会变成僵尸线程，持续占用系统资源，最终触发资源不足的错误，文档要求的“卸载前join”既是规范，也是避免资源泄漏的必要操作。

2. Erlang调度器对阻塞进程的处理
   当调用NIF的进程因为erl_drv_thread_join阻塞时，该进程会被标记为不可运行状态，Erlang调度器会立刻将它从运行队列中移除，转而调度其他可运行的进程。直到join操作完成，该进程才会重新回到运行队列等待调度。这种情况下，只会暂停当前调用NIF的进程，不会影响其他Erlang进程的正常执行。

3. NIF函数的响应时长限制
   Erlang本身没有硬性的响应时长限制，但有几个需要注意的点：

• 如果NIF函数执行时间过长（比如超过几十毫秒），会影响Erlang系统的调度公平性——因为NIF运行在调度器线程上（你这里是在NIF里创建线程后join，本质还是阻塞当前进程），长时间阻塞会让该调度器无法处理其他Erlang进程；
• 业务代码层面的超时机制（比如gen_server:call/3的超时参数）可能会因为NIF响应过久而触发超时，但这不是NIF本身的限制；
• 长时间运行的NIF任务如果占用过多CPU、内存，会影响整个节点的稳定性，但这也属于系统资源层面的约束，不是NIF的固有限制。

内容的提问来源于stack exchange，提问作者halfway258