[erlang-questions] Efficiency of passing data through port owner

[Chandru]

On 31/07/07, Richard Andrews <bbmaj7@REDACTED> wrote:
> I have a set of processes in mind:
>
> Receiver process assembles out-of-sequence parts of a large message sent by
> other processes so the whole message can go out a port as a binary when
> assembled.
>
> PortIO process handles data coming back from the port ExternalPort and as such
> is the port owner.
>
> I'm inexperienced with using ports and I'm looking for hints on how to
> efficiently get the data accumulated in Receiver out through ExternalPort. The
> obvious approach is to send the full message to PortIO which then sends it to
> ExternalPort, but I am concerned that this introduces inefficiency due to the
> size of the message.
>
> Would the above strategy result in a copy of the message binary being made from
> Receiver to PortIO prior to being pushed out the port?

Depends on the size of the message. Binaries smaller than 64 bytes (I
think) are copied whereas bigger binaries are passed by reference. See
http://www.erlang.org//doc/efficiency_guide/processes.html#5.2

>
> Is is possible to send directly from Receiver to ExternalPort (eg. registered
> port), but have data come back from ExternalPort into PortIO?
Yes.

> If possible, is it a recommended approach?
There is no reason not to do it this way. I would recommend this
approach so that the PortIO process does not become a bottleneck.

> Is it possible for PortIO to also reliably send messages and admin commands to
> ExternalPort in this situation?
Yes.

> Is there a potential for messages to get
> corrupted by interleaving if sent to the port from different processes at the
> same time?
No.

> Would TCP be better than a pipe-based port?
Ports are really meant as an access mechanism to existing programs on
the same host as the erlang node. If you want the flexibility to host
the two processes on different pieces of hardware then ports are not
suitable. On a UNIX box, Erlang ports use pipes as the IPC mechanism.
Not sure about Windows.

Chandru