Aggressive GC? Was Re: Untimely garbage collection

[Scott Lystig Fritchie]

>>>>> "bg" == Bjorn Gustavsson <bjorn@REDACTED> writes:

bg> Yes. If your driver haven't incremented the reference counter, you
bg> are in trouble.

bg> The compiler knows that the variables C and IOListBinary will not
bg> be used anymore; therefore, at this point no reference to them
bg> will be kept, and the next garbage collection the reference counts
bg> for the binaries will be decremented.

Those darn smart compilers!  They are so, umm, smart!  {sigh}

It's good to know that my current driver implementation is broken.  I
don't wanna fix it, but I guess there's a price to pay for 100%
correct behavior.  It's so sad when 99.99% correctness isn't good
enough.

Referring back to one of Shawn's messages ... I hadn't ever paid
attention to the "binv" member of the ErlIOVec structure.  Now I'm
quite interested!  The serialization scheme needed to get data into
the driver is very annoying -- I was under the impression that the
ErlIOVec completely hid the serialized data from me.  It's nice to
know I'm wrong.

I had discovered a problem with non-binary data in an I/O list:
write_port() allocates a buffer, "cbin" of "csize", for all non-binary
data.  write_port() frees that buffer immediately after calling the
driver's "outputv" method.  My thinking was: it's unsafe for an
asynchronous driver to try to access the non-binary data stored in
"cbin", so I'd force the Erlang code calling the driver to create
binaries for any non-binary data.

... However, upon another examination, write_port() is using
driver_alloc_binary(), *not* sys_alloc_from() or safe_alloc_from().
Driver binaries have a reference count!  If my driver increments the
refc of that thing, then I don't have to make the Erlang-side code so
contorted when given non-binary data.  Yay!

-Scott