1 / 5

Yet Another Tokyo Cabinet – Erlang binding

Yet Another Tokyo Cabinet – Erlang binding. Overview. Tokyo Cabinet Ultra-fast key-value data store Erlang Ultra-robust framework implementation for distributed systems Erlang interface for Tokyo Cabinet Standard binding interface is defined in tokyocabinet /tokyocabinet.idl

dustin
Download Presentation

Yet Another Tokyo Cabinet – Erlang binding

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Yet Another Tokyo Cabinet – Erlang binding

  2. Overview • Tokyo Cabinet • Ultra-fast key-value data store • Erlang • Ultra-robust framework implementation for distributed systems • Erlang interface for Tokyo Cabinet • Standard binding interface is defined in tokyocabinet/tokyocabinet.idl • Simple architecture • Related works • tcerl – good TC-erlang binding, with dets/ets/mnesia compatible interface

  3. Standard ErlangLinkedinDriver • Erlang code calls C code. • C code calls Erlang code. • Former. • Pros: high-thruput • Cons: higher-latency, C-module said to be bottleneck Call by message (using erlang:send/2), different thread context. Erlang code Returen by message (using receive),different thread context. C module

  4. Alternative ErlangLinkedinDriver • Using erlang:port_control/2 • (not send/2, port_command/2) • Pros: low-latency (expected) • Cons: lower-thruput(in fact, not so good) Call by function call (pushing onto stack), in same thread context. Erlang code Return by popping from stack. C module

  5. Alternative ErlangLinkedinDriver • int control(ErlDrvDatadrv_data, unsigned int command, char *buf, intlen, char **rbuf, intrlen) • This is a special routine invoked with the erlang function port_control/3. It works a little like an "ioctl" for erlang drivers. The data given to port_control/3 arrives in buf and len. The driver may send data back, using *rbuf and rlen. • This is the fastest way of calling a driver and get a response. It won't make any context switch in the erlang emulator, and requires no message passing. It is suitable for calling C function to get faster execution, when erlang is too slow. • If the driver wants to return data, it should return it in rbuf. When control is called, *rbuf points to a default buffer of rlen bytes, which can be used to return data. Data is returned different depending on the port control flags (those that are set with set_port_control_flags). • http://erlang.org/doc/man/driver_entry.html

More Related