On Sat, 05 Dec 2009, David Arturo Macias Corona wrote: Hi,
> "-s" is used to avoid "stack overflow checking", as OpenWatcom doc state: [...] I know what it does ;-) > I am unsure if switchs changes must be managed in hbmk2.prg too it's necessary only for C code calling APIENTRY16 functions. In whole Harbour SVN code only in GTOS2 such functions are used. If you do not plan to create and compile such C code using hbmk2 then it's not necessary to modify hbmk2. > >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 Please check if using current clean SVN code without any modifications you create working speedtst binaries using: hbmk2 speedtst -l -kmo -mt -gc3 -gtos2 to test execute them using: speedtst.exe --thread This is necessary to confirm that current workaround is working for GTOS2. Then please rebuild only speedtst using: hbmk2 speedtst -l -kmo -mt -gc3 -gtstd and repeat: speedtst.exe --thread if it does not work then we can try to use the same hack for GTSTD and check if it help. It will be an answer if it's enough to activate debug code to check stack overflow exactly for function which calls APIENTRY16 function or it's enough to make it on any upper level. This information will be usable in bug report for OpenWatcom users. Then I'll try to create small self contain example to exploit the problem. > ---------------------------------------------------------------- > 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. > ---------------------------------------------------------------- Thank you that you refreshed my mind but now we know more then when I wrote above text. I.e. we confirmed it's OW problem and we found workaround for it by enabling debug code which checks stack overflow. This code more or less indirectly resolves the problem. It's possible that it simply initialize some internal OW structures not initialized when thread is started so maybe it's enough to call any function compiled without -s as workaround. In such case instead of compiling GTOS2 with stack debug code we can simply add single function in separate .obj file which will be executed just after starting new thread. Above GTSTD tests can give the basic answer if it's possible or not. > Harbour 13130 or 13131 ? It doesn't matter. Functionally both make the same. It's only important you try clean SVN code without any local modifications or HB_* envvar settings. Thank you very much for your help. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
