[erlang-questions] What FFI to use for new code

Serge Aleynikov saleyn@REDACTED
Tue Dec 11 14:04:16 CET 2007


Joel,

If you are planning to write a book targeted for a more advanced 
audience, I can't possibly see how coverage of linked-in drivers can be 
avoided.  The EPP of the FFI implementation doesn't solve the need of 
asynchronous non-blocking invocation of C code, which is needed quite 
frequently in event-driven systems.  FFI is very convenient when you 
need quick access to stand-alone C functions or libraries.  Of course 
one can use FFI to implement queuing, threading, etc. on the C side, but 
then he/she would likely end up re-implementing features link-in drivers 
already offer.

I think it would be useful to cover link-in drivers from the following 
perspective:

1. C types: ErlDrvData, ErlDrvBinary, ErlIOVec, etc. and how to marshal 
terms to Erlang using these primitives.
2. Taking advantage of driver queues.
3. Monitoring health of Pids from C, and performing driver shutdown or 
resource cleanup when a Pid dies.
4. Highlighting differences between output methods (output, output2, 
outputv).
5. Handling events from other sources (driver_select, ready_input, 
ready_output and event callbacks) in the driver.
6. When to use ei and when not to.

At least there is currently no in-depth illustrated coverage of these 
subjects and one has to go through a broad trial-and-error cycle (at 
least I know I did :-( ) that keeps the learning curve pretty steep 
before he/she learns these concepts and the mysterious veil of driver 
complexity dissolves.

Serge

Joel Reymont wrote:
> I'm struggling to write the "C interface" chapter of my book. I would  
> like to write the Mac Cocoa bridge since it would cover XML processing  
> and maybe even a GUI chapter as well. I specifically want to write a  
> linked-in driver.
> 
> The main reason why I'm struggling is that I find the current linked- 
> in driver interface ... umm... very difficult to deal with. I don't  
> find the Erlang Driver Toolkit (EDTK) [1] or even Dryverl [2] to be a  
> great alternative.
> 
> Would it be reasonable to use the EEP for the Erlang FFI given that  
> the book won't come out for a few months?
> 
> 	Thanks, Joel
> 
> [1] http://www.snookles.com/erlang/edtk/
> [2] http://dryverl.objectweb.org/
> 
> --
> http://wagerlabs.com
> 
> 
> 
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
> 




More information about the erlang-questions mailing list