FFI Elixir/Erlang

[Matheus Caceres]

Hello,

How can I do to integrate pure lib C with Elixir or Erlang?

Does anyone have reading sugestions?

In my case, the I want a lib to integrate is https://github.com/google/gumbo-parser

Thanks.

[Steffen Bauer]

I would suggest to start with the Erlang Interoperability Tutorial Users Guide:

http://www.erlang.org/doc/tutorial/users_guide.html

I am currently writing a library to integrate Elixir with a C system library (ncurses). I am using the approach by NIFs, and it works very well so far.

[Matheus Caceres]

Thanks Steffen, the suggestion link help me! :)

[Saša Jurić]

Based on reports I have seen, I would probably go with ports, rather than NIFs.

The problem with NIF is that it runs inside the Erlang VM process, so if it crashes, the whole Erlang system is taken down. I've actually seen this happen with erlzmq (0MQ binding for Erlang).

Another thing I've seen being mentioned is that Erlang scheduler gets messed if the NIF execution takes longer time. Here's one reference:

http://erlang.org/pipermail/erlang-questions/2013-February/072448.html

Ports however run in a separate process, so if they crash, EVM still lives and can actually do something about it (e.g. restart the port). This is the approach I am using to run some ruby code from the EVM.

[Matheus Caceres]

Good reference Saša

Ports is a little more complex instead of NIF and taking into consideration after read reference and your quote about erlzmq, may be good think use ports.

But, the erlang community don't talking what's happen with NIF? Because, NIF it's more easy to integrate erlang language with C.

[Devin Torres]

Saša--

I believe you're thinking of C node's. Ports are just as caveat laden as NIFs.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Sasa Juric]

I was talking about this:

http://www.erlang.org/doc/tutorial/c_port.html

An external code which runs in a separate OS process and communicates with Erlang via stdio.

Not to be confused with port drivers which do run in EVM process and therefore suffer from similar problems as NIFs.

You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-talk/TeAwxf48llI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-ta...@googlegroups.com.

[Alexei Sholik]

Is there any benefit in communication via stdio? Setting up a socket connection, for instance, doesn't require any special interop between Erlang and the other process.

Best regards
Alexei Sholik

[Sasa Juric]

I'm no expert on the subject, but it seems to me that the difference is conceptual, more than mechanical.

A port is more like an Erlang process.

A C node is more like another Erlang node.

Conversely, starting of a port is initiated from Erlang, whereas starting of a C node will probably be initiated outside of the EVM.

If you control starting of a port from Erlang, you can for example start multiple instances of the same script, balance the request to them (for example via poolboy) and restart each one separately if it crashes.

Which is exactly what I do in production.

On a mechanical level, communication via stdio seems simpler in comparison to C node version.

(http://www.erlang.org/doc/tutorial/c_port.html#id62416 vs http://www.erlang.org/doc/tutorial/cnode.html#id64168)

[Tina Tsui]

Hi all,

I am trying to decide between NIF, port driver linking, C-port and C-node for my integration with some third party Windows DLLs that read files in a proprietary format.  I am leaning towards C-nodes for its distributed nature, since there may be more than one PC involved.  I am leaning towards TCP/IP socket communication (again to ease distribution). But distribution is easy done with a elixir server module that reads from the TCP/IP socket as well, so it doesn't have to be a C-node.  Another requirement is that the data I need to access via the DLLs is very large (over 1GB, but can be chunked) so there needs to be some part of my interface that shares the same memory space as the DLLs so I can control the chunking.

One thing I am confused about is that C-node relies on erl_interface for the communication and I have read that erl_interface has been deprecated in favor of ei.   More importantly, since I don't have the source to the Windows DLLs, I am limited to the platform that it is compiled in -- that is: I am restricted to using WIN32 compatible libraries and using Visual Studio 2010 (.NET version 4.5)  in linking the erlang libraries with the DLLs I need to use.  I am not a Windows expert, or Visual Studio expert, although I have managed to write a CPP program and compile with Visual Studio, a working executable that uses these third party DLLs.  I am more in my element with Unix and Unix IPC protocols and gcc.   Any advice on how to create an integration module (of any type: NIF, C-port or C-node) would be most welcomed!

Thanks,
Tina

[Vincent Siliakus]

Op vrijdag 13 september 2013 21:37:42 UTC+2 schreef Devin Torres:

Saša--

I believe you're thinking of C node's. Ports are just as caveat laden as NIFs.

While both can crash the Erlang VM, there's one important difference between port drivers and NIFs: NIF's can block the Erlang scheduler if its processing takes longer than a context switch.

While NIF's have the least overhead of all FFI options, they should generally not be used when a NIF call takes more than one millisecond.