Maurilio:
>The "bm" option must be specified since we are creating a multi-threaded
>application. If your multi-threaded application contains more than one
>module, each module must be compiled using the "bm" switch.
>So, it is not enough to buil hbvmmt with bm but all libs, but, doing
so, >what happens when I create an ST harbour program? That I'm,
actually, >always building MT executable?
>I did one more test and I've found that -bm has a great impact, on
>memory mostly, speedtst ST:
>T029 with -bm 22 sec.
>T030 with -bm 25 sec.
>T029 w/o -bm 1.6 sec.
>T030 w/o -bm 2.0 sec.
This is a known fact
My firsts builds were without -bm and they raise a warning in make_ow.log
Przemek indicate to include -bm
In that time results were, for ST:
- around 57 secs, without -bm
- around 104 secs, with -bm
so impact is very high
We leave -bm for now because we are testing threads problems
By now things are more complicated
As a brief summary, all for ST:
- around 57 secs, without -bm
- around 104 secs, with -bm
- around 107 secs, with -bm, without -s, with -sg
- around 149 secs, with -bm, without -s, without -sg
I suggest to you to read all messages since begin of OS/2-OW tests
There are a lot of info and so you will not get confused with known facts
When we isolated problem to kbdCharIn(), Mou...() functions execution, I
planned to research to areas:
a) KbdCharIn(), Mou...() area
Unless an oscure participation of KBD16CHARIN, I restisted to
consider these functions as problem
b) Harbour thread implementation-behaviour
I read some docs of OW and review code in thread.c, so I saw it uses
_beginthread() and I was "playing" with parameters values without
problem resolv
You were introduced to tests with a) area, but indirectly you show that
problem is related to b) area removing -s flag
My tests show that now does not GPF without -s flag, but run extremaly
low or even "freeze" using threads, but no without threads
And is not related to OS/2 32 threads limit which can be expanded with
performace decrease.
We are using speedtst.prg ... --thread=2
So problem are oriented to threads/stack management under Harbour and
are raised by differences in gcc335 / OW management
We should introduce differenciation for OS/2-OW in Harbour thread code ?
First we must see where there are differences
Now we know there are differences in _beginthread() - _beginthreadx()
(just Win32) and _beginthread() - _beginthread() in Win32-OS/2
We are not understanding OW behaviour/features which rely in platform
So I was adding doc pages to help to clarify
OS/2-OW is a different beast :-)
In my messages I requested to review/understand OW sample with threads
in hope to get "some light" how thread must be managed
Was my intention but not requested, to make other type of tests:
"separate Harbour - C"
- Build a C-only code test using OW / threads based in OS/2-OW
rules/features/flags/doc/...
- Run same C.only code test using gcc335 / threads and compare results
between gcc335 - OW
- Replicate same test with Harbour threads implementation and compare
results with two C-only tests
It can show:
- Need or not to introduce different code for gcc/OW in Harbour
- Need or not to introduce changes in Harbour threads/stack/memory
management
I still does not understand why we should test with speedtst/ST mode if
we are looking for stack use, which are only relevant for threads except
1 in OS/2, but not in Win32, due to _beginthread() use
_beginthread( , stack, ) is used for thread 1 / no threads ?
I understand that -sg is adding 4k pieces to stack, but what happen when
we have fixed code in thread.c/_beginthread() for stack parameter ? It
is ignored ?
For me 128 * 1024 is a large quatity, double of fixed stack=65536 used
for thread 1 in OS/2-OW, but not Win32-OW
-s flag stated: "Stack overflow checking is omitted from the generated
code", but we have "stack overflow" condition with used values ?
65536 for thread 1 and 128 * 1024 for rest of threads, in OS/2
-s info does not say what does if "Stack overflow checking" is enabled.
It increase value ?, generate runtime error, ... ?
Many of these concepts/handling are out of my knowledge
David Macias
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
