Port driver communication witout copy of binaries
Wed Mar 29 09:19:33 CEST 2006
There are two main differences. One making it faster than
non-copying port_command, and one making it slower...
erlang:port_call( Port, Cmd, DATA )
Converts DATA to the erlang external term format. The driver
then has to use conversion functions in the erl_interface
and ei C libraries to get to the raw data. The driver also
has to provide the return value in erlang external term
These conversions forces data to be copied in both directions
since the external term format is not the same as the internal.
The term conversions are to facilitate using port_call/3
to mimic BIFs.
The return value is returned to the erlang caller
without process scheduling, so there is no delay in the
return value transport. Also like BIFs.
Handles raw byte data. The return value is placed in the
caller's inbox (normally), so it has to be fetched using
receive in erlang. This is more like send/receive towards
a server and hence slower than calling a BIF or port_call/3.
So, for implementing a BIF of your own, erlang:port_call/3
is faster. For bulk data transport non-copying
erlang:port_command/2 is more efficient.
(Valentin Micic) writes:
> Is there any reason for not using:
> erlang:port_call( Port, Cmd, DATA )
> which results in call to linked-in driver's:
> int edk_call( ErlDrvData handle, unsigned int cmd, char * buf, int
> len, char **rbuf, int rlen, unsigned int * flags )
> Argument DATA specified in erlang's port_call is passed by
> reference. The driver may return data in rbuf. Should there be more
> memory required that specified by rlen, such memory may be allocated,
> using driver_alloc... no need to free rbuf, as it points to automatic
> I've been using this approach for integration with some ss7
> adapter... to cut the story short, it's working just
> fine. Documentation is indicating that this is the fastest way to
> interact with driver.
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
More information about the erlang-questions