[erlang-questions] linked in driver port performance

[Sverker Eriksson]

Actually, NIFs don't use ports so there is no locking at all needed to 
call a NIF, except
the locks already held on the running process. If you introduce data 
that could be shared
between concurrent NIF calls, then you have to serialize that access 
with your own
locking. Using enif_mutex_* for example.

You can't use async-threads from a NIF, but you can create custom 
threads with
enif_thread_create and send messages from that thread with enif_send.

/Sverker, Erlang/OTP

Michael Truog wrote:
> Ok, I didn't realize that you had found the same linked in driver
> permanent issue on trapexit.  I at least offered my explanation of what
> you seem to be experiencing.
>
> After looking at NIFs, they actually look like they are using port level
> locking by default (as described at
> http://erlang.org/doc/man/erl_nif.html by the "Threads and concurrency"
> section).  It would be much easier to create a NIF, but there is no
> interface for async threads through NIFs (though you can send a process
> a message with enif_send, which might help facilitate asynchronous
> behavior).  If you stick with a port driver, you would need to use
> ERL_DRV_FLAG_USE_PORT_LOCKING as previously mentioned.  Either way you
> want the C code to be quick, so you don't block the Erlang VM scheduler
> thread.
>
> - Michael
>  
> On 07/13/2010 10:10 PM, Michael Truog wrote:
>   
>> I think you are having problems with the driver becoming permanent when
>> you make the first asynchronous call (there is code that locks the port
>> driver so the dll/so can not be unloaded (so it can't be reloaded)). 
>> The code is trying to protect the code from the possibility that a
>> thread finishes but the port driver has already been unloaded, which is
>> a valid concern (but could be handled in more complex ways).  The
>> problem has been mentioned before here
>> http://www.trapexit.org/forum/viewtopic.php?t=14295&sid=5de3c47e32136682080511d8d95d458e
>> .
>>
>> ERL_DRV_FLAG_USE_PORT_LOCKING is the flag to make sure different
>> scheduler threads can call the port driver instances concurrently (the
>> entry in the driver_flags struct member
>> http://www.erlang.org/doc/man/driver_entry.html#driver_flags) as
>> discussed here http://www.erlang.org/doc/man/erl_driver.html#smp_support
>> .  I assume NIFs use the port driver default of "driver level locking"
>> (driver_flags == 0, i.e., not ERL_DRV_FLAG_USE_PORT_LOCKING), but I am
>> not sure.
>>
>> - Michael
>>
>> On 07/13/2010 08:28 PM, Vinubalaji Gopal wrote:
>>   
>>     
>>> Hi all,
>>>   I have been digging hard to write a port linked in driver which would
>>> perform better and most of my searches resulted in dead threads (like
>>> http://www.trapexit.org/forum/viewtopic.php?t=14295&sid=5de3c47e32136682080511d8d95d458e)
>>> and most of my experiments did not give me any good results . I tried to use
>>> async threads but I am not able to call these async threads asynchronously.
>>> If I try to make multiple erlang processes open the same port it just fails
>>> saying that the driver has become permanent. If I try to open a single port
>>> driver  - I have to do that in a single gen_server and it blocks when I
>>> call  port_command - so all the messages are queued and processed
>>> sequentially. Is there a way to write a linked in driver which will perform
>>> better and/or better links to help (I have read the erl_driver
>>> documentation, erl_ddll documentation numerous times).
>>>
>>>
>>>
>>>   
>>>     
>>>       
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>>
>>   
>>     
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>