Przemek:
Harbour code does not make any difference in this problem.
It's only OpenWatcom bug.
So the only one solution is removing -s option.
In such case we have to find the method to pass information from
src/rtl/gtos2/Makefile to config/os2/watcom.mk that -s should not
be used. I can quite easy hack it introducing new variable like
HB_CSTACK_CHECK=yes
but maybe Viktor has some other propositions which will better
integrate with all other make parameters?.
Viktor I'll add above HB_CSTACK_CHECK but if you prefer other names
or different solution then please modify it.
"-s" is used to avoid "stack overflow checking", as OpenWatcom doc state:
--------------------------
-s flag
=======
Stack overflow checking is omitted from the generated code. By default,
the compiler will emit code at the beginning of every function that
checks for the "stack overflow" condition. This option can be used to
disable this feature. The macro __SW_S will be predefined if "s" is
selected.
--------------------------
I am unsure if switchs changes must be managed in hbmk2.prg too
In reported tests I used changes in src\rtl\gtos2\makefile(switchs) and
wpp386.exe (switchs) command line, **without** hbmk2
For example:
wpp386.exe -zq -bt=os2 -w3 -bm -6r -fp6 -ei -zp4 -zt0 -oi+ -onaehtr -sg
-s ...
Perhaps is time to request help to OpenWatcom developers
Yes, though it will be rather bug report.
For sure current behavior have to be fixed in OpenWatcom.
I suppose same apply for gtstd
Have you checked it?
GTSTD does not call internally any OS2 APIENTRY16 function so it
should not exploit the problem. If it does then it means that
OpenWatcom CTRL functions kbhit()/getch() internally calls APIENTRY16
functions and where compiled with -s switch so they have the same
problem.
I am based in older tests/messages, from Nov 2008
Tests with gtos2, gtstd, gtcgi lead us to find as conclusion problem is
related to "input devices" in threads except 1 (keyboard, mouse, ...)
Failed with gtos2, gtstd but not gtcgi
Some older messages portions ( I skipped many messages ):
Re: Harbour under OS/2 - OpenWatcom
Sat Nov 8 10:10:40 EST 2008
As you can see with GTCGI it's related to GT.
Looks like it's caused by keyboard related functions when
executed from non main thread.
--------------------------------------------------
Sat Nov 8 12:00:32 EST 2008
in hb_gt_def_InkeyPollDo() executes low level GT driver READKEY()
method. In GTOS2 it's hb_gt_os2_ReadKey(). Please also note that
it works for 1-st thread and fails only for the second one so the
problem is bound with low level GT code. In GTCGI READKEY() does
nothing and only returns K_ENTER code:
static int hb_gt_cgi_ReadKey( PHB_GT pGT, int iEventMask )
{
HB_TRACE(HB_TR_DEBUG, ("hb_gt_cgi_ReadKey(%p,%d)", pGT, iEventMask));
HB_SYMBOL_UNUSED( pGT );
HB_SYMBOL_UNUSED( iEventMask );
return 13;
}
In GTOS2 and GTSTD low level keyboard code is activated and it causes
that application fails.
----------------------------------------------------------------
Sun Nov 9 10:39:48 EST 2008
HB_GT_OS2_DEFAULT and HB_GT_STD_DEFAULT should fail equal, but STD does
a step ahead (??)
----------------------------------------------------------------
Mon Nov 10 08:09:34 EST 2008
So it's general problem with accessing console from other threads.
[...]
To be precise it's KbdPeek() and kbhit() is probably simple wrapper to it.
It means that OW internals are also effected by this problem.
The question is if it can be resolved or not. Is it OW bug or problem
with OS2 API. In GCC it seems to be resolved. The question is how.
----------------------------------------------------------------
If you have a while then please download current SVN code (it should
have new workaround which disable -s only for GTOS2) then compile it
and make test using:
speedtst.exe --thread
linked with GTSTD, i.e.:
hbmk2 speedtst.prg -l -kmo -gc3 -gtstd
Such information may be important for OpenWatcom developers.
Harbour 13130 or 13131 ?
David Macias
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
