[erlang-questions] When to release resources in NIF?

Attila Rajmund Nohl <>
Mon Mar 24 16:34:55 CET 2014


Hello!

I do have those, the problem is that I don't see any difference in the
unload call when the module is explicitly removed using code:delete/1
and code:purge/1 or implicitly removed during a code upgrade. In the
first case I have to delete the locks, in the second case I don't have
to. I've ended up with this code:

    static int load(ErlNifEnv* env, void** priv_data, ERL_NIF_TERM load_info) {
        /* create locks */
        return 0;
    }

    static void unload(ErlNifEnv* env, void* priv_data) {
        if (NULL != priv_data) {
            /* delete locks */
        }
    }

    static int upgrade(ErlNifEnv* env, void** priv_data, void**
old_priv_data, ERL_NIF_TERM load_info) {
        unload(env, *old_priv_data);
        *old_priv_data = NULL;
        load(env, priv_data, load_info);
        return 0;
    }

It works, but I'm not sure how and why.

2014-03-24 15:17 GMT+01:00 Soup <>:
> Theoretically, you should be able to use the "upgrade" or "reload" callbacks
> in your NIF instead of the unload callback. It may be necessary to perform
> the upgrade as an app/relup to use that feature, though. Perhaps someone a
> bit more versed on NIF modules can shed some light.
>
> At the very least you need to specify one of those two callback functions.
>
> ~Soup
>
>
> On Fri, Mar 21, 2014 at 1:15 PM, Attila Rajmund Nohl
> <> wrote:
>>
>> Hello!
>>
>> I have a NIF module that uses a locks to protect a common resource.
>> The locks are created using enif_rwlock_create in the load function
>> and destroyed in the unload function. When I first load the Erlang
>> module, the locks are initialized and everything is OK. When I compile
>> the module in the same VM the first time, everything is still OK. When
>> I compile it the second time, the old version of the module is
>> unloaded, so unload is called. At this point I'm in trouble, because
>> the unload function destroys the lock.
>>
>> I'm not quite sure how to correctly handle this situation. Somehow I
>> should keep (or destroy/create) the locks in the upgrade step, but
>> after the second compilation the locks are already deleted by unload.
>> I could add a flag to the private data stating that the locks were
>> already destroyed or not, but it feels hackish. What is the correct
>> way?
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>


More information about the erlang-questions mailing list