[erlang-questions] driver interfaces

[Heinrich Venter]

Hi all

 

I just want to make sure that I understand the driver interface basics
correctly.

 

driver_command/2

Takes iodata as data

Delivers to the output callback as binary or array

Returns values asynchronously with a driver_output call

-If the outputv callback is set, this is used instead and delviers the data
as ErlIOVec (which is faster)

 

driver_controll/3

Takes iodata as data

Delivers to the controll callback as binary or array

Returns values synchronously with results in the supplied rbuf parameter

-Return values may be either eterm format or binary

-Fastest according to docs

 

driver_call/3

Takes an erlang term as data

Delivers to the call callback as pointer to eterm

Returns values synchronously with results in the rbuf parameter

-Return values must be in eterm format

 

It would seem that each has its own uses.

driver_controll is useful for exposing C  functions most directly.  For this
the calling erlnang code should send a binary, packed with the parameters in
the native format.  Returned values will be a binary, again in the native
format.

 

driver_call is useful if you want to create functions that look more like
erlang functions than C functions.  You have to decode the sent terms and
encode the responses through ei.

 

driver_command is useful if you need to do asynchronous calls.  Perhaps also
useful in a multithreaded driver that does long computations (in combination
with driver_async)?

 

Some things I don't quite understand:

Is the output callbacks format also determined by set_port_controll_flags
like form the controll callback?

 

Might it be useful to have a controll type callback that delivers the data
as ErlIOVec, for the same optimisation reasons as for the output callback?

 

Is driver_output2 useful?  Is there an efficeincy issue with matching on a
binary on the erlang side, or does this function predate binary matching?

 

Is it more efficeint to use driver_output_binary than driver_output if it is
known beforehand that the port is in binary mode?

 

Any further insights would be appreciated

 

-]-[einrich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20070513/43a53867/attachment.htm>