On Wed, 04 Mar 2009, Francesco Saverio Giudice wrote:

Hi,

> do you think that this problem is related to memory consumption in uhttpd ? 

No. I do not see such possibilities.

> I'm struggling doing tests and I was thinking that the problem was related 
> to PRIVATE variables. But now I have an uhttpd version that uses only 
> STATIC / THREAD STATIC variables and if I don't use hb_GCAll() memory grows 
> with 4kb/8kb steps, also using a single page view, continuously. Instead 
> using hb_GCAll() after initial growing it stops to grow around 10MB of 
> memory (starting from 7MB), but randomly, application GPFs without any 
> report (once after ~60 connections, another after ~8000 connections, up to 
> 15 concurrent threads).
> Actually I have tested with defaults C flags (without memory allocation 
> flags) and using msvc, but previous tests (with current version on SVN) I 
> did with all combinations you wrote to Pritpal and using either msvc than 
> bcc.

Replacing privates with statics is rather bad idea. Privates are
automatically dealocated when they are out of scope. statics exist
for the whole application life so when they are not longer necessary
and you want to clear the items inside you have to make it yourself.
Of course it depends on application context. But to clarify before
other people begin to change his code. There is nothing technically
wrong in using memvars (private and publics). If you want and like
them then use them. For sure it will be many times faster and consume
less resources then emulating memvar behavior at .prg level using
statics or locals what IMHO is technical nonsense.

I can try to look at uhttpd but it will have to be updated to work
in Linux. At least in some special test mode. Can you update it?
I tried to compile it with INET support and the following functions
are missed:
   WIN_SYSREFRESH(), WIN_TIMEZONEBIAS(), WIN_SETENV(), FILEDATE()
The last one is from hbct and can be easy replaced by:
   HB_FGETDATETIME( <cFile>, [ @<dDate> ] [, @<cTime> ] ) -> <lOK>
Please use it if possible instead FILEDATE(). It will reduce dependencies
list.
I'll add hb_setenv() function which can be used to replace WIN_SETENV().
I can also add hb_utcoffset() which will return difference to UTC+0000
in minutes which you can used instead of WIN_TIMEZONEBIAS().
How to replace WIN_SYSREFRESH() is your decision.
But maybe it will be good to add some compile time switch like USE_HB_INET
to disable all above WIN_*() functions. In such version we can test this
code using current core Harbour libs only without any additional C stuff.
If you can update it so it can be executed as simple console application
in Linux then I'll try to locate what's the reason of problems.

BTW, Viktor I tried to compile it using hbmk2 uhttpd.hbm and -gui
switch is translated to -Wl,-mwindows. It's wrong even also in
real MinGW. -mwindows/-mconsole are GCC not LD only switches. If you
do not inform GCC about them then it's possible that you exploit
some problems just like with -Wl,-static.
Only MS-Windows GCC builds support these switches. For sure MinGW.
I do not know if CygWin does. For sure they should not be enabled
in other GCC ports, f.e. in Linux in this case.

best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to