Port driver memory free

[casper2000a@REDACTED]

Hi Raimo,

Thanks for the detailed explaination. Still I have 2 questions.

1. In PORT_CONTROL_FLAG_BINARY mode, control function should return a binary. So I usually 
allocate a binary by calling driver_alloc_binary function. As per your explaination the emulater uses 
driver_free to deallocate it. Will this create a problem? (allocate using driver_alloc_binary and 
deallocate using driver_free)

2. Erlang Maual says at page ERTS->driver_entry->control "Note that this binary must be freed".

- Eranga



Quoting Raimo Niskanen : > Quoting Raimo Niskanen :

> The short answer is: do not free! 
> 
> To elaborate:
> * In binary mode, you must return a binary:
> ErlDrvBinary *binp = driver_alloc_binary(len);
> /* Copy len bytes of data to to binp->orig_bytes */
> *rbuf = (char *)binp;
> return len;
> The caller (the emulator) will increment the refcount and take care 
> of deallocation when the binary is no longer used.
> * In list mode, if the supplied result buffer is too small, you
> should allocate a new result buffer using driver_alloc(size),
> and the caller (the emulator) will free it it has fetched the
> result from it. Otherwise just write the result in the supplied
> result buffer. The emulator compares the returned buffer address
> with the supplied buffer address to see if you return an allocated
> buffer. So, if you set *rbuf, it _must_ be to something allocated 
> with driver_alloc(size), because it _will_ be freed with 
> driver_free(*rbuf). You can of course return an allocated buffer
> for any size, also less than 64 bytes.
> 
> 
> 
> casper2000a@REDACTED (Casper) writes:
> 
> > Hi All,
> > 
> > There are 2 parameters, **rbuf and rlen in Port Driver entry \"control. In
> > PORT_CONTROL_FLAG_BINARY mode, I should pass a driver_binary in **rbuf.
> > Usually rlen is 64, which mean **rbuf has 64 bytes, if I need to use that
> > without creating a new ErlDrvBinary. My questions are,
> > 
> > 1. If my final ErlDrvBinary size is < 64 bytes and I use **rbuf without
> > allocating a new ErlDrvBinary, should I still call driver_free_binary or
> > driver_free to free that **rbuf memory before \"control\" function returns?
> > 
> > 2. If my final ErlDrvBinary size is > 64 bytes and I allocate a new
> > driver_binary and assign to **rbuf, what will happen to the previous 64
> > buffer which was in **rbuf? Will the port or erlang garbage collecter free
> > that? Or do I need to free it inside the \"control\" function by calling
> > driver_free_binary or driver_free?
> > 
> > 3. I (2) above, what will be the case if I use driver_realloc or
> > driver_realloc_binary? Will the previous 64 byes get released?
> > 
> > 4. I (2) above, I still need to call driver_free_binary to free the newly
> > created driver_binary inside \"control\" function, correct?
> > 
> > 5. If I call \"set_port_control_flags(dd->port, 0)\" to set the port output
> to
> > non-binary, do I need to free or clear the non-used space of **rbuf?
> > 
> > 6. In above cased which free function, driver_free_binary or driver_free
> and
> > which allocation function, driver_alloc, driver_alloc_binary,
> > driver_realloc, driver_realloc_binary should I use?
> > 
> > Thanks in advance!
> > - Eranga
> > 
> > 
> 
> -- 
> 
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> 

--------------This mail sent through OmniBIS.com--------------