Hi Przemek,
Il 05/03/2009 21.46, Przemyslaw Czerpak ha scritto:
The problem is still there :-(
Not this one.
Surely not PRIVATE, I was meaning the "memory consumption problem".
This happens with uhttpd in current SVN version *without* hb_GCAll() calls.
You are using complex items with cyclic references. Only GC can free them
so it's always necessary to execute it. If you are using such structures
then GC call is a must for you.
Ok, I will consider this.
Only if I add hb_GCAll() it will works without growing continuously, but:
- I got (one time at the moment) that application random freeze
The socket.c module does not unlock HVM before waiting on socket function
and can cause such effects. Try with hb_inet*() functions.
Already tested with both and with same results (OS memory consumption).
Probably you should also update your win main loop to call
hb_vmUnlock() / hb_vmLock() before and after the sleep.
Ok
- Memory used (when new threads is added/released) it is not released
Which memory?
Working memory as reported from Task Manager, not internal harbour memory.
Harbour does not use any thread local memory at all.
You store in this code a lot of different items which are never cleared
but only overwritten by subsequent call. It's not a problem but as long
as all of them will not be assigned then memory usage will growing up
to some limit. Then they will be overwritten so nothing wrong will happen.
It's not a bug. Just simply result of your code.
Ok, I will try to make it better, and suggestions will always well accepted.
I'm doing other tests, also with (unpublished) version that uses only
STATIC / THREAD STATIC vars. But yesterday tests show that memory grows as
in default version.
I would be extremely surprised if it will not.
As I said moving to static you are increasing number of items you
assign and never clear. And now you are asking why the memory usage
is bigger. Yes it is. It has to be bigger.
But it's not a problem as long as it's not result of some infinite
growing.
I know that you are right, this is my knowledge limit.
I will test for curiosity where is the memory limit.
Now I will try to make it working in Linux so you can will test by yourself.
I ported it last night. Except some problems with MT safe code and
the PRIVATE usage inside the loop I do not see any problems with
memory usage. The memory usage was as it should be though I only
make some simple tests.
Anyhow if you can update this code so it can be compiled for *nixes
then it will be very nice.
Ok
One note you should remember. Each .hrb module loaded 1-st time
allocates symbol table which is never freed but only marked as
free when module is unloaded. It' later reused when .hrb module
is loaded next times. Maybe you are watching at memory usage caused
by this.
Actually I have used only two tests:
1st is a single html file that does a simple page refresh every 1
second, so no HRB module is loaded, called many times using more tabs
from browsers (Chrome, Opera, IE, FF).
2nd is /testxmldb.html that has inside a sleep that permits to add
threads with repeated calls and this uses HRB, but it is always the same.
Thank you for your time.
Best regards,
Francesco
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
