Port driver memory free

[Raimo Niskanen]

1. No, driver_free is used in list mode; directly after the result list
   has been created. In binary mode the binary is not freed, it is 
   passed to the receiving process and will be properly freed once the
   garbage collector finds it is not used anymore.
2. I guess the manual is unclear or even wrong. Like for plain result
   buffer you cannot free until after you have returned, which is
   impossible, so therefore, conceptually, the emulator frees the
   result buffer - even when it is a binary. (I hope I do not have to
   eat this mail if that statement proves wrong) Generally, if you
   allocate a binary you will have to free it when you do not use
   it anymore, but in this special case of returning it as a result;
   if you want to hang on to it you will have to increment its
   refcount before you return. But _if_ you keep the binary after
   returning it - you can not change it because the emulator, compiler
   and all programmers assume that a term can not change value.
   As a special feature, from R10B, you can also return NULL instead of
   a binary, which will arrive as [] to the receiving erlang process
   which is handy when you do not want to return anything, and want
   to do it fast.



casper2000a@REDACTED writes:

> 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--------------
> 

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB