[erlang-questions] linked in driver port performance

[Michael Truog]

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).
>
>
>
>