"erl_drv_output_term" vs "driver_output_binary" ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

"erl_drv_output_term" vs "driver_output_binary" ?

Frank Muller
Hi there,

I would like to know the difference between the two calls.

My linked-in driver has to send big (~4MB in average) binaries to the Erlang owning process. 

1. Which call is better suited from that ?
2. Does every binary gets copied or just reference counted?
3. Any better alternative to use?
4. Anything else I should be aware of?

Many thanks...
/Frank

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: "erl_drv_output_term" vs "driver_output_binary" ?

Raimo Niskanen-2
On Fri, Jul 21, 2017 at 09:11:24AM +0000, Frank Muller wrote:
> Hi there,
>
> I would like to know the difference between the two calls.
>
> My linked-in driver has to send big (~4MB in average) binaries to the
> Erlang owning process.
>
> 1. Which call is better suited from that ?

driver_output_binary(port, NULL, 0, bin, offset, len) will be received by
the owning process as {Port,{data,Bin}}.  A containing integer list can be
added using hbuf != NULL.

erl_drv_output_term(port, term, n) will be received by the owning process
simply as Term.  This involves parsing the term in ErlDrvTermData[] format
to be able to produce any term.

> 2. Does every binary gets copied or just reference counted?

Binaries from a driver gets reference counted with either of these APIs.

> 3. Any better alternative to use?

I think these are fairly equivalent except that one produces a term on a
predefined format.

> 4. Anything else I should be aware of?

If your driver needs the binary after sending it to Erlang it will have to
increment the reference count itself, and free it later after decrementing
the reference count.

The driver can not change the data in the binary after sending it to
Erlang.  That has very undefined consequences.

>
> Many thanks...
> /Frank


--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: "erl_drv_output_term" vs "driver_output_binary" ?

Frank Muller
Thanks Raimo. I'll stick with "driver_output_binary" for now. 

/Frank

Le ven. 21 juil. 2017 à 11:44, Raimo Niskanen <[hidden email]> a écrit :
On Fri, Jul 21, 2017 at 09:11:24AM +0000, Frank Muller wrote:
> Hi there,
>
> I would like to know the difference between the two calls.
>
> My linked-in driver has to send big (~4MB in average) binaries to the
> Erlang owning process.
>
> 1. Which call is better suited from that ?

driver_output_binary(port, NULL, 0, bin, offset, len) will be received by
the owning process as {Port,{data,Bin}}.  A containing integer list can be
added using hbuf != NULL.

erl_drv_output_term(port, term, n) will be received by the owning process
simply as Term.  This involves parsing the term in ErlDrvTermData[] format
to be able to produce any term.

> 2. Does every binary gets copied or just reference counted?

Binaries from a driver gets reference counted with either of these APIs.

> 3. Any better alternative to use?

I think these are fairly equivalent except that one produces a term on a
predefined format.

> 4. Anything else I should be aware of?

If your driver needs the binary after sending it to Erlang it will have to
increment the reference count itself, and free it later after decrementing
the reference count.

The driver can not change the data in the binary after sending it to
Erlang.  That has very undefined consequences.

>
> Many thanks...
> /Frank


--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: "erl_drv_output_term" vs "driver_output_binary" ?

Frank Muller
One more question Raimo: how about the opposite scenario: Erlang sending big binary to the driver?

1. Is the binary simply reference-counted?
2. What if the Erlang side change the binary after 
sending it? Should I worry about that?

/Frank


Thanks Raimo. I'll stick with "driver_output_binary" for now. 

/Frank

Le ven. 21 juil. 2017 à 11:44, Raimo Niskanen <[hidden email]> a écrit :
On Fri, Jul 21, 2017 at 09:11:24AM +0000, Frank Muller wrote:
> Hi there,
>
> I would like to know the difference between the two calls.
>
> My linked-in driver has to send big (~4MB in average) binaries to the
> Erlang owning process.
>
> 1. Which call is better suited from that ?

driver_output_binary(port, NULL, 0, bin, offset, len) will be received by
the owning process as {Port,{data,Bin}}.  A containing integer list can be
added using hbuf != NULL.

erl_drv_output_term(port, term, n) will be received by the owning process
simply as Term.  This involves parsing the term in ErlDrvTermData[] format
to be able to produce any term.

> 2. Does every binary gets copied or just reference counted?

Binaries from a driver gets reference counted with either of these APIs.

> 3. Any better alternative to use?

I think these are fairly equivalent except that one produces a term on a
predefined format.

> 4. Anything else I should be aware of?

If your driver needs the binary after sending it to Erlang it will have to
increment the reference count itself, and free it later after decrementing
the reference count.

The driver can not change the data in the binary after sending it to
Erlang.  That has very undefined consequences.

>
> Many thanks...
> /Frank


--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: "erl_drv_output_term" vs "driver_output_binary" ?

Raimo Niskanen-2
On Fri, Jul 21, 2017 at 12:24:11PM +0000, Frank Muller wrote:
> One more question Raimo: how about the opposite scenario: Erlang sending
> big binary to the driver?
>
> 1. Is the binary simply reference-counted?

Yes.  If the driver implements the driver_entry outputv().

> 2. What if the Erlang side change the binary after
> sending it? Should I worry about that?

Nope.  All terms are read-only, from Erlang's point of view.

>
> /Frank
>
>
> Thanks Raimo. I'll stick with "driver_output_binary" for now.
> >
> > /Frank
> >
> > Le ven. 21 juil. 2017 à 11:44, Raimo Niskanen <
> > [hidden email]> a écrit :
> >
> >> On Fri, Jul 21, 2017 at 09:11:24AM +0000, Frank Muller wrote:
> >> > Hi there,
> >> >
> >> > I would like to know the difference between the two calls.
> >> >
> >> > My linked-in driver has to send big (~4MB in average) binaries to the
> >> > Erlang owning process.
> >> >
> >> > 1. Which call is better suited from that ?
> >>
> >> driver_output_binary(port, NULL, 0, bin, offset, len) will be received by
> >> the owning process as {Port,{data,Bin}}.  A containing integer list can be
> >> added using hbuf != NULL.
> >>
> >> erl_drv_output_term(port, term, n) will be received by the owning process
> >> simply as Term.  This involves parsing the term in ErlDrvTermData[] format
> >> to be able to produce any term.
> >>
> >> > 2. Does every binary gets copied or just reference counted?
> >>
> >> Binaries from a driver gets reference counted with either of these APIs.
> >>
> >> > 3. Any better alternative to use?
> >>
> >> I think these are fairly equivalent except that one produces a term on a
> >> predefined format.
> >>
> >> > 4. Anything else I should be aware of?
> >>
> >> If your driver needs the binary after sending it to Erlang it will have to
> >> increment the reference count itself, and free it later after decrementing
> >> the reference count.
> >>
> >> The driver can not change the data in the binary after sending it to
> >> Erlang.  That has very undefined consequences.
> >>
> >> >
> >> > Many thanks...
> >> > /Frank
> >>
> >>
> >> --
> >>
> >> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> >> _______________________________________________
> >> erlang-questions mailing list
> >> [hidden email]
> >> http://erlang.org/mailman/listinfo/erlang-questions
> >>
> >

> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions


--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions