Port driver memory free
Thu Mar 17 09:16:34 CET 2005
The short answer is: do not free!
* 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;
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.
> 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
More information about the erlang-questions