Thu Jun 28 10:14:08 CEST 2001
Sean Hinde wrote:
> > This is kind of what I thought from the docs but crypto seems
> > to do it a
> > little differently.. Here there is a server process which
> > opens the driver,
> > "owns" it, and puts the port reference in a 'protected' ets
> > table (i.e. read
> > allowed by all). The client functions read this table and call
> > erlang:port_command in the context of the *calling* process.
> Hmm, I just made a driver which does both mechanisms and the one which does
> port_control in the calling process averages 20uS per call but the one which
> uses driver_output averages about 35uS.
I would just like to mention that when a process calls port_command, the
->output code in the driver is executed, (perhaps) an answer is
generated and placed in the process's receive queue. Then port_command
returns and the process does a receive, which matches out the answer
from the receive queue. This implies more overhead than port_control,
which is just a BIF call that delivers the return value.
Also, port_command involves some more treatment of the buffer passed
down, to cope with the cases of the driver having an ->outpuv function,
etc. In this respect port_control is very starightforward.
And, port_control also have less overhead when returning data, at least
in the case when the data is less than 64 bytes (which you cannot rely
The backdraws of port_command is that it is more limited, e.g no
vectorized output, cannot return binaries with list head
(driver_output2()), _cannot_ return an asynchronous reply, and certanly
/ Raimo Niskanen, Ericsson UAB, Erlang/OTP
More information about the erlang-questions