On Thu, 26 Nov 2009, David Arturo Macias Corona wrote:
Hi,
> About:
> "When Maurilio changed some OpenWatcom switches used to control calling
> convention then the problem disappeared"
>
> The problem never disappeared. After his tests I explained about
> switches and suggested him to review entire messages related to
> tests
> Before we tried with any switch combinations and never resolved. I
> have track of it
> So we are as we left in December 2008
Sorry but now I'm really confused. All what I know about results
of real life OS/2 test comes from you and Maurilio messages.
Now I'm OpenWatcom builds reading that it was never working
correctly in MT mode in whole Harbour history and always fail
in MT mode when second thread accessed GTOS2 function (I guess
that speedtst works correctly with current SVN code when is linked
with GTCGI).
Can you and Maurilio confirm it?
> The proper way is to review those messages to recall tests state,
> refresh our minds and then continue with new suggestions
Did it work in the past after modifications in build time switches or not?
If not then there is no reason to look for old messages.
> As was and is "hard to locate the exact problem" perhaps we should
> leave to resolve after Harbour 2.0 ( Dec 2009, "Harbour Winter 2009
> edition" )
To be clear. It _was_ hard to locate to exact problem but after your
test I know the exact problem so this part is resolved and it's not
related to Harbour source code at all. The problem is caused by code
generated by OpenWatom for functions which have in their body calls to
some of APIENTRY16 functions like KbdCharIn(). When non main thread
tries to execute such function then it GPFs. It's unimportant how
APIENTRY16 function is used. Important is only the fact that it's
used. I.e. if we have function like:
static int hb_gt_os2_ReadKey( PHB_GT pGT, int iEventMask )
{
return 0;
}
then it works but if we have function like:
static int hb_gt_os2_ReadKey( PHB_GT pGT, int iEventMask )
{
if( pGT == NULL )
KbdCharIn( s_key, IO_NOWAIT, ( HKBD ) * s_hk );
return 0;
}
Then it will GPF though pGT is always not NULL so KbdCharIn() is never
executed.
Above conclusion is the result of your test done in last year.
So there is only question about finding workaround in OpenWatcom build
configuration to resolve it. Of course if such workaround exists.
I thought that more or less intentionally Maurilio found it and it
was committed to Harbour repository.
These should be switches related to C stack usage i.e. switches to
control calling convention.
It's also possible that we may find some programing workaround,
i.e. using functions to encapsulate calls to APIENTRY16, i.e.
void hb_os2_KbdCharIn( PKBDKEYINFO pKbdInfo, USHORT flags, HKBD hKbd )
{
KbdCharIn( pKbdInfo, flags, hKbd );
}
and then use hb_os2_KbdCharIn() in hb_gt_os2_ReadKey() instead of
KbdCharIn(). It may help because hb_gt_os2_ReadKey() is used indirectly
by pointer to function and maybe only in such situation the OpenWatcom
bug is exploited. But such method is only hack which may not work or
suddenly stop to work in the future due to compile and link time
optimizations, i.e. compiler may automatically inline above function
creating the same code as for initial version.
> but if you want ( and I want ) to resolve immediatly, give me
> guidelines :-)
If you have some time to make tests then we can try to look for
workarounds for the problem but 1-st I would like to be sure if it
was working in the past and if yes then restore exact build time
switches used for working version to locate the ones which helped
to resolve the problem.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
