NIF vs. Linked-in Drivers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: NIF vs. Linked-in Drivers

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


Sergej

On Tue, Dec 8, 2009 at 6:03 PM, Evans, Matthew <[hidden email]> 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?
>
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: NIF vs. Linked-in Drivers

Sverker Eriksson
In reply to this post by Evans, Matthew
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

Reply | Threaded
Open this post in threaded view
|

Re: NIF vs. Linked-in Drivers

Max Lapshin-2
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.

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

Reply | Threaded
Open this post in threaded view
|

Re: NIF vs. Linked-in Drivers

Ulf Wiger-3
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

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

Reply | Threaded
Open this post in threaded view
|

Re: NIF vs. Linked-in Drivers

Max Lapshin-2
On Tue, Dec 8, 2009 at 11:15 PM, Ulf Wiger
<[hidden email]> 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.

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

Reply | Threaded
Open this post in threaded view
|

Re: NIF vs. Linked-in Drivers

Björn-Egil Dahlberg
In reply to this post by Ulf Wiger-3
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


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