weekend erlang programmer


{2009, 5, 9}

erl_interfaceについて 23:21 はてなブックマーク - erl_interfaceについて - weekend erlang programmer erl_interfaceについて - weekend erlang programmer のブックマークコメント



  • 上側のerlangからオブジェクトatomとかlistとか)をCのbuilt-in typesに渡したり、
    • ei_decode_hogehogeを使う
  • Cで処理した結果をerlangに渡すためのデコードをやったりする
    • ei_encode_hogehogeを使う


open_portなどについてしらべてみるなどする 08:34 はてなブックマーク - open_portなどについてしらべてみるなどする - weekend erlang programmer open_portなどについてしらべてみるなどする - weekend erlang programmer のブックマークコメント

you can call open_port several times and get several 'driver instances'. open_port returns the pid of the driver and you only have to send messages to that pid to use port.

[erlang-questions] curious

Though driver-based C interop API is fast, it does incur around 20-30us overhead for a function call in the current implementation (though I last benchmarked it in R11B-5), whereas an FFI-based approach can be made more optimal (at the cost of potential loss of robustness, yet often that is an acceptable sacrifice for the sake of performance gain when bridging Erlang to other C/C++ libraries).

[erlang-questions] State of the Union: FFI

An erlang port (reading from stdin/stdout in a separate OS process) could be used. If there were absolutely no errors, it would be trivial to switch it to an erlang port driver (running as a VM process in a more efficient way), but that is at your own risk of being harder to debug.

[erlang-questions] Calling into Lua from Erlang

Here's how I'm using open_port and killing the spawned process. You may be able to use something similar. Platform specific as well.

[erlang-questions] Stopping a port from within erlang

The bit which surprised me was that sending a kill to a port started with open_port({spawn, ...}, [...]) doesn't necessarily kill the unix process. It merely closes the file file descriptors. This is a problem when the external process gets stuck in a loop somewhere and thus stops caring about stdin/stdout.

how to kill a port's external process?