Driver question

Sean Hinde Sean.Hinde@REDACTED
Tue Aug 28 20:41:11 CEST 2001


A further question about the suggestion below:

> Yes they do. They might be exactly what you need. The driver binaries
> are reference counted, and when you call driver_allocate_binary(),
> refcnt is set to 1 (only the driver is holding the binary).
> When you later call driver_output_binary(), refcnt is 
> incremented to 2,
> and note that the driver must not change the contents from 
> now on, since
> erlang processes now can see the data and depend on this. The driver
> migth as well call driver_free_binary(), which just decrements refcnt.
> Only when refcnt decrements to 0, the binary is actually freed.
> Every erlang process that now receives the binary will 
> increment refcnt,
> and when the binary is garbage collected and found to be unused refcnt
> is decremented and finaly freed by the last erlang processe 
> that garbage
> collects it.

I have played with this somewhat.. I allocate the binary in the driver and
send the result to erlang. The refc is now 2 (although it sometime goes to 3
for a short time?). I do not free it at this time as I want to read the refc
in a future call to my driver and then if it is back to 1 I can free up a
whole load of other stuff as well as the binary.

I have a fixed size array of handles so it is possible for them all to be
used up in which case I return "congestion".

The behaviour I can't quite figure out though is that of
erlang:garbage_collect(). If I call this, the binaries are not immediately
reduced to refc = 1. It takes something like 10 seconds before any of them
are freed and then some appear to never be freed.

My binaries are 2 octets long.

Any thoughts on the behaviour of the garbage collector in this situation?


This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.

More information about the erlang-questions mailing list