Port driver memory free

Casper <>
Wed Mar 23 12:22:17 CET 2005


You are right. But what I am saying is if I have to change the architecture
of the program, for example change the Port Driver to a C Port or C Node,
then I loose the efficiency which I targeted by choosing Port Driver method
in the first place.

For example, to my understanding, to split Erlang and my C code, I need to
change the Port Driver behavior. There won't be driver->control,
driver->call, driver->event, etc. I will not use driver_alloc_binary,
driver_free_binary functions. Then I will not know the correct method of
writing a Port Driver.

Well, if I convert the code to be a something other than Port Driver, yes, I
will know that Port Driver part created the problem. If there's no any other
workaround solution to identify the problem, I guess I will do that and see.

- Eranga

-----Original Message-----
From:  [mailto:] 
Sent: Wednesday, March 23, 2005 4:59 PM
To: Casper; 
Subject: RE: Port driver memory free

On Wed, 23 Mar 2005 13:28:53 +0600, "Casper" <>

> if I have to change the Architecture to convert my Port driver to an
> external Port or Node, I loose the track of the memory leak point.

Your saying oposite of what makes sense.  When you divide into two
processes then you do not loose track but you have better track.  Three

One.  Memory leak goes away.  That was point of exorcise.  Now you know
the leaking it is in interface code.  Very short example with just
leaking code and nothing more possible now.  Maybe the mistake in how
you call interface.

Two.  beam continuse leaking.  P{roblem allmost certain in erlang code.

Three.  c process continuse leaking.  Problem is in C code.


More information about the erlang-questions mailing list