[erlang-questions] NIF vs. Linked-in Drivers

[Evans, Matthew]

Hi,

Are there any guidelines as to the use of the new Erlang NIF vs. a linked-in port driver?

We have an application that needs to access C code, and are currently thinking (and have used in the past) a linked-in port driver. Under what situations would that approach be better than a NIF, and visa versa?

Also, we all know that a linked in driver can crash or lock the Erlang runtime system if the driver is poorly implemented. Do these risks still exist with NIFs?

Thanks

Matt

[Rapsey]

NIF libraries are linked into erlang just like linked in drivers. If they
crash, so does beam process.

Sergej

[Sverker Eriksson]

Evans, Matthew wrote:
> Hi,
>
> Are there any guidelines as to the use of the new Erlang NIF vs. a linked-in port driver?
>
> We have an application that needs to access C code, and are currently thinking (and have used in the past) a linked-in port driver. Under what situations would that approach be better than a NIF, and visa versa?
>
>

A driver is definitely better if you want to be asynchronous and react
on events from some "device".

NIFs are by nature synchronous. You call them as any Erlang function and
get a return value back. You will block the calling scheduler thread
until the NIF returns, so you don't want to do too heavy computations in
one call. Drivers currently have more support like threading and message
sending to work around that, but the NIFs will most probably get at
least some sort of support to be more "interruptable".

/Sverker, Erlang/OTP Ericsson

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Max Lapshin]

In my linked-in driver fork of sqlite3 driver, NIF function is
absolutely unusable, because sqlite3 library will block calling
process,
thus all functions are executed in async thread.

But linked-in driver is harder to implement.

[Ulf Wiger]

Max Lapshin wrote:
> In my linked-in driver fork of sqlite3 driver, NIF function is
> absolutely unusable, because sqlite3 library will block calling
> process,
> thus all functions are executed in async thread.
>
> But linked-in driver is harder to implement.

If you have a limited number of instances of a blocking
NIF, you could add that number of extra schedulers to
the system when you start Erlang. Not sure if that would
have any particular bad side-effects... perhaps the VM
experts know?

BR,
Ulf W
--
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com

[Max Lapshin]

On Tue, Dec 8, 2009 at 11:15 PM, Ulf Wiger
<ulf....@erlang-consulting.com> wrote:
> If you have a limited number of instances of a blocking
> NIF, you could add that number of extra schedulers to
> the system when you start Erlang. Not sure if that would
> have any particular bad side-effects... perhaps the VM
> experts know?

Linkedin driver subsystem has excelent capabilities to schedule long
task on pool of threads.
It seems, that it will be required to implement thread pool with NIF.
Am I wrong?

NIF is especially useable, while adding rare functions from system
API, that are missed in ERTS.

[Björn-Egil Dahlberg]

Ulf Wiger wrote:
> Max Lapshin wrote:
>> In my linked-in driver fork of sqlite3 driver, NIF function is
>> absolutely unusable, because sqlite3 library will block calling
>> process,
>> thus all functions are executed in async thread.
>>
>> But linked-in driver is harder to implement.
>
> If you have a limited number of instances of a blocking
> NIF, you could add that number of extra schedulers to
> the system when you start Erlang. Not sure if that would
> have any particular bad side-effects... perhaps the VM
> experts know?

One reason of why it is bad to have more schedulers then processing
units is because of spinlocks. You can do it but it is far from optimal.

Regards,
Björn-Egil
Erlang/OTP