* utils/hbmk2/hbmk2.prg
! Fixed to work on newer Darwin systems (f.e. latest XCode
with gcc 4.2.1). -Wno-long-double option had to be removed.
This way hbmk2 is in sync with GNU Make.
* source/vm/thread.c
! Fixed to compile HB_MT().
* harbour/source/vm/thread.c
+ added HB_MT() PRG function which exists only in MT HVM version and
can be REQUESTed from .prg code to force linking MT HVM.
* harbour/contrib/hbnetio/utils/netiosrv.prg
! fixed typo in port parameter support
* modified name of second parameter. Instead of 'address' use 'ifaddr'
(interface address) which seems to be more precise name.
* added 'request HB_MT' to protect linking with HVM without MT support.
* harbour/include/hbsetup.h
* harbour/include/hbthread.h
* harbour/include/hbatomic.h
* harbour/source/vm/thread.c
* added support for MT mode in WinCE builds using raw MS-Windows API
instead of CRTL wrappers. It's possible that it may badly interact
with some CRTLs functions we are using in our code so I do not know
it will work. Please test.
+ harbour/include/hbtask.h
+ harbour/source/vm/task.c
* harbour/include/hbthread.h
* harbour/include/hbatomic.h
* harbour/source/vm/thread.c
* harbour/source/vm/hvm.c
* harbour/source/vm/fm.c
* harbour/source/rtl/idle.c
* harbour/source/rtl/filesys.c
+ implemented OS independent task switching system - it gives PTHREAD
compatible basic API so it can be used in HVM as alternative MT support
which does not use any OS threads. As long as Harbour does not call
any blocking OS function then it's possible to create and execute
simultaneously many threads though only one CPU is used and switched
between HVM threads. It gives similar scalability to xbase++ threads
and also similar behavior in item protection at .prg level.
Now it's possible to use HVM threads in any OS.
Of course it does not mean that Harbour adds in some magic way
thread support to OS-es which does not support threads like DOS.
It only means that HVM supports threads for .prg code just like
in native MT environment as long as some C code does not block
task switching or process execution will not be frozen by sth, i.e.
executing other process (__run()) in single process OS like DOS.
In some cases it can be interesting alternative even in OS which
have native thread support.
All tests/mttest*.prg programs and speedtst --thread=<n> --scale
are executed correctly with new task switching just like with
OS native MT support.
Compilation with task switching in hbvmmt library can be forced
by HB_TASK_THREAD macro which also disable native OS threads
support.
For task context switching two alternative methods are used:
1) getcontext()/makecontext()/swapcontext() (SUSv2, POSIX.1-2001)
which is preferable because does not need any additional
hacks but not all OS-es supports these functions.
It's enabled by default in Linux builds.
2) setjmp()/longjmp() (POSIX, ISO 9899 (C99)) otherwise.
These functions are supported by most of C compilers
but there is no function to set new stack in saved context
so it's necessary to introduce for each architecure/C compiler
peace of code which makes it. Macro HB_TASK_STACK_INIT() in
task.c makes it. I defined this macro for x86@32 in DJGPP
Linux GCC and OpenWatcom builds. I tested OpenWatcom builds only
in DOS and Linux but probably it works in all x86@32 builds.
If someone is interesting in adding support for some other
platforms which does not support ucontext.h and 1-st methods
then please define above macro for them.
Have a fun with new toy ;-)
* harbour/source/vm/Makefile
* enabled hbvmmt in DJGPP and OpenWatcom DOS builds. It works well.
Viktor if possible please add support for -mt switch in hbmk2
in all builds even if we do not compile hbvmmt by default so
it can be used with DJGPP and OW and any other builds for which
someone enable hbtask.c though OS does not support threads.
* harbour/contrib/hbmzip/hbmzip.c
! fixed '[const] char|BYTE *' casting in DOS and OS2 builds
* harbour/include/hbapi.h
* harbour/source/vm/extend.c
* renamed existing hb_par*() and hb_stor*() functions which supports
variable number of parameters (...) into hb_parv*() and hb_storv*()
* added new hb_par*() and hb_stor*() functions which use strict number
of parameters. New hb_par*() functions do not make hidden conversion
between types, f.e. hb_parl() returns 1 only for logical parameters
which contain .T.
* harbour/include/extend.api
* map Clipper _par*() functions to hb_parv*()
* map Clipper _stor*() functions to hb_storv*()
* harbour/source/vm/dynsym.c
* harbour/source/vm/hvm.c
* harbour/source/vm/maindllp.c
* harbour/source/vm/thread.c
* harbour/source/vm/classes.c
* harbour/source/rtl/cdpapi.c
* harbour/source/rtl/mlcfunc.c
* harbour/contrib/hbnf/dispc.c
* harbour/contrib/hbnf/mouse.c
* harbour/contrib/hbnf/getenvrn.c
* harbour/contrib/hbhpdf/harupdf.c
* harbour/contrib/gtwvg/wvgcuig.c
* harbour/contrib/gtwvg/wvgwin.c
* harbour/contrib/gtwvg/wvgutils.c
* harbour/contrib/gtwvg/wvgcore.c
* harbour/contrib/gtwvg/wvgwing.c
* harbour/contrib/rddads/adsfunc.c
* harbour/contrib/rddads/ads1.c
* harbour/contrib/rddads/adsmgmnt.c
* harbour/contrib/hbmisc/hb_f.c
* harbour/contrib/hbwin/wapi_commctrl.c
* replaced hb_par*() and hb_stor*() calls used with additional parameters
by hb_parv*() and hb_storv*()
TODO: update examples/hbwhat/*.c files
* harbour/examples/uhttpd2/socket.c
* harbour/examples/httpsrv/socket.c
* changed hb_parni() to hb_parnidef()
* harbour/source/vm/itemapi.c
* removed some conversion which are not necessary for CA-Cl*pper
compatibility
* harbour/source/macro/macrolex.c
* replaced HB_LEX_IS*() macros by by HB_IS*() ones
* utils/hbmk2/hbmk2.prg
+ Added preliminary support for autosetup for several more
compilers: win/watcom, win/pocc, win/pocc64, wce/poccarm,
dos/djgpp, dos/watcom.
Only these were tested: dos/djgpp, win/watcom, win/pocc.
This means it's now possible to "bundle" DJGPP, watcom or
pocc _compiler tools_ with Harbour and hbmk2 will be able
to detect them, or user can choose between them using
-arch/-comp switches, then hbmk2 will just be able to use
them "as is", without the need to change anything on the
environment. zero-conf usage in essence, just like we
already had for mingw family.
; NOTE: Before the release I'll rethink placement of these
tools inside the Harbour directory tree. Currently
they are detected in the Harbour root dir, but with
multiple compilers this is not ideal.
* source/vm/thread.c
! Fixed compile error after 2009-06-16 08:55 UTC+0200.
* include/hbextern.ch
* source/vm/thread.c
+ Added HB_MUTEXWAITERSCOUNT() to core.
(slightly rewritten using local functions)
- examples/uhttpd2/umutex.c
- No longer needed.
* harbour/source/vm/eval.c
* update number of parameters in HB_EXECMSG() to keep the HVM stack
clean for any external code which can try to make some HVM stack
tracing/scanning
* harbour/source/vm/evalhb.c
! use hb_vmSend() instead of hb_vmDo()
* harbour/source/pp/pplib.c
* harbour/source/pp/pplib3.c
* harbour/source/vm/runner.c
* harbour/source/vm/hvm.c
* harbour/source/vm/thread.c
* harbour/source/vm/eval.c
* harbour/source/vm/dynlibhb.c
* harbour/source/vm/classes.c
* harbour/source/rtl/do.c
* harbour/source/rtl/xhelp.c
* harbour/source/rdd/workarea.c
* harbour/source/rdd/dbf1.c
% use hb_vmProc() instead of hb_vmDo() in all places where context is
well known as function or procedure call
* harbour/include/hbvm.h
* harbour/source/vm/hvm.c
+ added hb_vmProc() function - it's hb_vmDo() but without hack to send
messages.
TODO: remove from hb_vmDo() support for messages so it can replace
new hb_vmProc() function or if we really need such mixed common
execution function then replace in HVM calls to hb_vmDo() with
hb_vmProc()
* harbour/source/vm/classes.c
* replaced hb_vmFunction() call by hb_vmDo()
* harbour/source/vm/arrays.c
* harbour/source/vm/thread.c
! cleaned hb_vmDo()/hb_vmSend() usage
* harbour/source/vm/eval.c
! replaced hb_vmFunction() calls by hb_vmSend()
+ added .prg function hb_execMsg( <sFuncSym>, <object>, [<params,...>] )
which executes <sFuncSym> with <object> set as QSELF() value.
Mindaugas, you can use it in your HashObject to execute functions
like pseudo messages.
* harbour/include/hbclass.ch
+ extended support for xbase++ compatible method declaration:
[SYNC] METHOD <methodName1>[([<params>])] ;
[ , <methodNameN>[([<params>])] ]
* harbour/include/hbthread.h
* harbour/source/vm/thread.c
* harbour/source/vm/classes.c
+ added alternative support for SYNC method which does not use
sync mutexes. The old method is still present. I'll remove it
when xbase++ users confirm that the new one exactly emulates
xbase++ behavior.
* harbour/source/vm/classes.c
* harbour/source/rtl/tthreadx.prg
* switch to alternative SYNC method implementation which seems to be
xbase++ compatible - please test
! fixed missing thread interrupt in recent modification for ::setInterval
* utils/hbdoc/genos2.prg
* utils/hbdoc/genng.prg
* utils/hbdoc/genasc.prg
* utils/hbdoc/genchm.prg
* utils/hbdoc/genhpc.prg
* utils/hbdoc/ft_funcs.prg
* utils/hbdoc/hbdoc.prg
* utils/hbdoc/genhtm.prg
* utils/hbdoc/genpdf1.prg
* utils/hbdoc/gentrf.prg
* utils/hbdoc/genrtf.prg
+ Enabled line number for all files to aid finding crashes.
! Few crashes fixed. Still far from usable state.
* source/vm/thread.c
+ Added short Harbour level API description. (from Przemek)
* contrib/xhb/Makefile
* contrib/xhb/hbcompat.ch
+ contrib/xhb/xhbmt.prg
+ Added translation for all xhb MT functions.
(Thanks a lot Przemek)
* harbour/include/hbpp.h
! changed the NOT operator precedence - it should be bigger then
logical .and./.or. operators in #if expressions
* harbour/source/vm/thread.c
! fixed typo HB_OS_WIM -> HB_OS_WIN - thanks to Francesco.
* harbour/include/hbthread.h
* harbour/source/vm/thread.c
* emulate POSIX thread conditional variables in Windows builds.
It should fix some possible bad behavior in MS-Windows Harbour
MT programs.
* harbour/source/rtl/hbinet.c
! fixed typo in HB_INETDATAREADY() - the second parameter (timeout)
was ignored.
* harbour/contrib/examples/uhttpd/uhttpdc.c
* fixed typo in conditional iMsec usage.
* harbour/contrib/examples/uhttpd/uhttpd.prg
* set default timeout for socket operations to 3 sec.
* use timeout parameter in HB_INETDATAREADY() and
increased default timeout for accept to 250 millisecs.
Please correct this modification if you prefer different values.
+ harbour/config/linux/icc.cf
* harbour/config/linux/gcc.cf
* harbour/bin/hb-func.sh
* harbour/bin/postinst.sh
* harbour/source/common/hbver.c
+ added support for Intel(R) C/C++ compiler
* harbour/bin/postinst.sh
% use hb-mkdyn symlink instead of regenerating it as hb-mkslib
It will work also in DOS/Windows (MSys/DJGPP emulates ln -s ...)
* harbour/source/vm/thread.c
* removed all references to HB_THREAD_EQUAL()/HB_THREAD_SELF() in
non MT builds
* harbour/source/rtl/console.c
! fixed default color setting in hb_dispOutAtBox()
* harbour/contrib/gtwvg/wvggui.h
* harbour/contrib/gtwvg/wvgwin.c
* harbour/contrib/gtwvg/wincallb.c
* harbour/contrib/gtwvg/wvgsink.c
! fixes for C++ compilation:
- this is reserved word in C++ - do not use it as variable name
- class is reserved word in C++ - do not use it as variable name
- use macros to hide differences between C and C++ WinAPI
- casting
* harbour/source/vm/thread.c
! fixed the typo in order of sending signals in _hb_thread_cond_signal()
_hb_thread_cond_broadcast() for OS2. By mistake it was LIFO instead of
FIFO.
* harbour/include/hbthread.h
* harbour/source/vm/thread.c
! added support for conditional variables working like in PTHREADS
in OS2 builds - it fixes the problem with possible dead lock or
starvation effect which can also cause dead lock in some cases.
OS2 users please test current code.
* harbour/source/vm/thread.c
! fixed typo in PTHREAD (*nixes) version of hb_threadMutexTimedLock()
(.prg HB_MUTEXLOCK() with timeout parameter)
! unlock HVM in *nix version of hb_threadWait()
; added TODO note
* harbour/include/hbthread.h
* harbour/source/vm/thread.c
! fixed a bug on OS/2 MT implementation adding a new function,
_hb_cond_timed_wait() because when a semaphore gets posted it has
to be reset, otherwise it does not stop new threads entering it in a wait.
* harbour/include/hbthread.h
* harbour/source/vm/thread.c
+ added hb_atomic_set(), hb_atomic_get(), hb_atomic_inc() and
hb_atomic_dec() functions which operates on HB_COUNTER or smaller
type if it's necessary for some platforms which can be access/assign
increment/decrement in MT safe atom operations.
hb_atomic_dec() returns true if counter is 0 after decrementation
* harbour/include/hbatomic.h
! fixed compilation in Linux and OpenWatcom
* harbour/include/hbapiitm.h
* harbour/source/rtl/itemseri.c
+ make hb_itemSerialize() and hb_itemDeserialize() public functions
! fixed serialization items with internal item references
* harbour/source/vm/hvm.c
* release memvars after closing RDDs
* harbour/source/debug/dbgentry.c
! fixed buffer overflow reported by Rodrigo
* harbour/source/vm/macro.c
* harbour/source/compiler/hbmain.c
* formatting
* harbour/include/hbexprb.c
! fixed wrongly recognized functions with HB_I18N_ prefix as
HB_I18N_GETTEXT()
* harbour/include/hbapi.h
* harbour/include/hbstack.h
* harbour/include/hbthread.h
* harbour/source/vm/estack.c
* harbour/source/vm/thread.c
* harbour/source/vm/hvm.c
+ added support for I18N in HVM.
Each thread can have it's own i18n set.
When new thread is created then it inherits i18n set from parent
thread and both uses the same set (please remember about it if you
will want to make some direct modifications on active i18n set
internals).
When thread change active i18n set then it effects only this thread
and new threads which will be create later. It does not change i18n
in other existing threads.
+ added functions to set/get pointer to active i18n set in HVM
void * hb_vmI18N( void )
void hb_vmSetI18N( void * )
* harbour/include/hbapi.h
* harbour/source/rtl/hbi18n.c
+ added i18n module. Now only for internal Harbour usage without support
for optional switching to alternative implementations.
I'll add such functionality later when I will work on native gettext
support.
The following public .prg functions has been added:
HB_I18N_GETTEXT[_STRICT]( <cMsgID> [, <cContext> ] )
-> <cTranslatedMsgID> | <cMsgID>
HB_I18N_NGETTEXT[_STRICT]( <nValue>, <cMsgID> | <acMsgID> ;
[, <cContext> ] )
-> <cTranslatedMsgID> | <cMsgID> | <acMsgID>[ <nIndex> ]
This is minimal support necessary for .prg code which has to exists
in each i18n module working with Harbour.
The following functions had been added as public C API:
PHB_ITEM hb_i18n_gettext( PHB_ITEM pMsgID, PHB_ITEM pContext )
PHB_ITEM hb_i18n_ngettext( PHB_ITEM pNum,
PHB_ITEM pMsgID, PHB_ITEM pContext )
The following functions had been added as private HVM C API:
void hb_i18n_init( void )
void hb_i18n_exit( void )
void hb_i18n_release( void * cargo )
void * hb_i18n_alloc( void * cargo )
They have to be supported by alternative i18n modules
The following functions has been added to manage Harbour i18n
translations sets:
HB_I18N_CREATE()
-> <pI18N>
Creates new empty I18N translation set
HB_I18N_CODEPAGE( [<pI18N>,] [<cNewCP>], [<lBase>], [<lTranslate>] )
-> <cOldCP>
Gets or sets Harbour codepage used by translation set
<pI18N> - I18N translation set,
if it's not given then currently active I18N set is used
<cNewCP> - new CP ID. Must be linked with application
<lBase> - when it's .T. then get/set base massages CP instead of
translated massages CP
<lTranslate> - if it's .T. then translate base (<lBase>==.T.) or
final messages in I18N set from previous CP to
given one. Base messages translation in synced
with context ID translation.
HB_I18N_PLURALFORM( [<pI18N>,] [<cNewForm>|<bNewForm>], [<lBase>] )
-> <cOldForm>|<bOldForm>
Gets or sets plural form used for final or base messages
<pI18N> - I18N translation set,
if it's not given then currently active I18N set is used
<cNewForm> - language ID of plural form, f.e.: "EN", "PL", "LT".
Now only three above are supported. Please add rules
for other languages to source/rtl/hbi18n.c.
<bNewForm> - codeblock used to calculate plural form indexes.
can be used instead of character representation but
it's not storred in serialized I18N set
<lBase> - when it's .T. then get/set base massages plural form
instead of translated massages one.
HB_I18N_DESCRIPTION( [<pI18N>,] [<cNewDescription>] )
-> <cOldDescription>
Gets or sets translation set description. After serialization
up to 32 bytes is stored in header which can be easy used to
determinate type of translation file.
<pI18N> - I18N translation set,
if it's not given then currently active I18N set is used
<cNewDescription> - new description
HB_I18N_ADDTEXT( <pI18N>, <cMsgID>, <cTrans> | <acTrans> [, <cContext> ] )
-> NIL
Adds new message with translation to i18n translation set
<pI18N> - I18N translation set
<cMsgID> - original message
<cTrans> - translated message
<acTrans> - array with translated messages used for plural forms
<cContext> - message context
HB_I18N_SET( [ <pI18N> | NIL ] )
-> <lActive>
Sets given I18N translation set as default one used by
HB_I18N_[N]GETTEXT[_STRICT]() functions or remove translation
set for calling thread when passed parameter is NIL
<pI18N> - I18N translation set
Returns logical value which is .T. when i18n set is active
HB_I18N_SAVETABLE( [<pI18N>] )
-> <cTable>
Returns I18N translation as string item which can be stored
in file or database
<pI18N> - I18N translation set, if it's not given then currently
active I18N set is used
HB_I18N_RESTORETABLE( <cTable> )
-> <pI18N> | NIL
Restores I18N translation set from strin item.
<cTable> - I18N translation set in string representation
On success it returns new <pI18N> set otherwise NIL if <cTable>
is not valid item created by HB_I18N_SAVETABLE() or it's corrupted.
HB_I18N_HEADERSIZE()
-> <nHeaderSize>
Returns size of header used by i18n serialized version
HB_I18N_CHEK( <cTable> | <cHeader> [, @<cDescription> ] )
-> <lValid>
<cTable> - i18n translation set serialized by HB_I18N_SAVETABLE
<cHeader> - header of i18n translation set
( LEFT( <cTable>, HB_I18N_HEADERSIZE() )
<cDescription> - optional parameter passed by reference where
will be sored i18n translation set description
extracted from valid header
Returns logical value indicating if given table or header is
valid serialized by HB_I18N_SAVETABLE() data. It does not
decode the table though it validates size and control sums.
These functions are optional and some future alternative implementations
may not support all of them and/or may provide some other functions.
+ added unofficial .prg function __I18N_HASHTABLE() which allows to
access hash table used by i18n translation set or create new translation
set with given hash table. It's helper functions for developers which
will work on Harbour i18n tools and should not be used by Harbour users.
Unlike original gettext Harbour allows to use language with many
plural forms as base one. In such case programmer should activate
at application startup default i18n translation set with base plural
form valid for base application language, f.e. by:
pI18N := hb_i18n_create()
hb_i18n_pluralForm( pI18N, <cLangID> | <bForm>, .t. )
hb_i18n_set( pI18N )
.prg code example:
#xtranslate _( <x,...> ) => hb_i18n_gettext_strict( <x> )
#xtranslate _N( <x,...> ) => hb_i18n_ngettext_strict( <x> )
proc main()
local pI18N, i
pI18N := hb_i18n_create()
hb_i18n_pluralForm( pI18N, "PL", .t. )
hb_i18n_set( pI18N )
for i := 0 to 30
? i, _N( i, {"grosz", "grosze", "groszy"} )
if i > 0 .and. i % 10 == 0
wait
endif
next
return
In .pot files created during compilation by Harbour with -j option
for above code we have the following entries for message with plural
forms:
msgid "grosz"
msgid_plural "grosze"
msgid_plural2 "groszy"
msgstr[0] ""
The msgid_plural2 (and others if language has more plural forms)
is Harbour extension which is not gettext compatible.
The above implementation is base version but should be fully functional.
Now we will need functions to safe/read i18n files and tools to mange
.pot files: merge them, edit translations, create final binary i18n
translation sets. Because we are using gettext compatible .pot files
then for some of such jobs we can use original gettext tools but we
need at least function which will create translation set from one or
more .pot files.
We should also agree some default localization(s) for files containing
translated data, their name convention and environment variable(s)
to set default language. It's not strictly necessary and each user
can have his own implementation but it would help in adding new
translations by final users to any Harbour application which will
respect them. We can use LANG envvar to extract preferred language
and use the same path as executed application looking for files
<appname>-<lang>.hil files though it may create some problems for
OSes which support only 8.3 file names so we can also define that
HB_I18N envvar has higher priority and points to expected translation
file.
* harbour/include/hbextern.ch
- removed old __i18n_*() functions
+ added current i18n functions
* harbour/source/vm/thread.c
* removed casting to void* thread startup function passed
as _beginthread() parameter in OS2 builds. It should be checked if
it does not breaks GCC builds.
* harbour/source/rtl/seconds.c
* use getpid() instead of _getpid() in non GCC OS2 builds
* harbour/include/hbthread.h
* harbour/source/vm/thread.c
+ added ULONG _hb_gettid( void ) to OS2 builds - thanks to Maurilio
* harbour/source/rtl/hbinet.c
* changed a little bit the order of including header files in OS2 builds
(blink fix for OpenWatcom OS2 builds).
* harbour/source/rtl/gtxwc/gtxwc.c
* added hack for problems with some XLIB versions in heavy stress
MT tests
* harbour/include/hbapigt.h
* harbour/source/vm/thread.c
* added parameter to hb_gtAlloc() C function
* harbour/include/hbapigt.h
* harbour/source/rtl/hbgtcore.c
+ added hb_gtCreate() and hb_gtSwap() C functions
+ added new .prg functions:
HB_GTCREATE( <cGtName> ) -> <pGT>
HB_GTSELECT( <pGT> ) -> <pPrevGT>
Using this functions is possible to create many console window
if GT supports such possibilities (f.e. GTXWC or GTWVT) even in
single thread programs and switch between them.
* harbour/source/rtl/box.c
! fixed one of recent DISPBOX() modifications - it should use:
hb_gtBoxEx() instead of hb_gtDrawBox() to set cursor position.
+ harbour/tests/gtwin.prg
+ added demonstration/test code for using more then one console window
also in single thread programs.
* harbour/include/hbstack.h
* harbour/include/hbgtcore.h
* harbour/include/hbthread.h
* harbour/include/hbapigt.h
* harbour/source/vm/estack.c
* harbour/source/vm/hvm.c
* harbour/source/vm/thread.c
* harbour/source/rtl/hbgtcore.c
+ added support for optional allocating independent console window by
each thread. By default new thread inherits console Window from
parent thread. But each thread can allocate its own console window
by calling hb_gtReload( <cGtName> ) function, f.e. by:
hb_gtReload( hb_gtVersion() )
If GT driver supports such functionality then new it will allocate
new console windows.
Each console window has reference counter which is increased when
new thread starts and decreased when hb_gtReload() is executed or
thread terminates. When counter reach zero give console window is
destroyed.
* harbour/source/rtl/gtwvt/gtwvt.c
! use SendNotifyMessage() instead of SendMessage() to not block
threads which inherited GT from parent thread. Why non of MS-Win
users reported this problem?
+ added reference counter to window class for multi GT support
+ harbour/tests/mt/mttest10.prg
+ added demonstration/test code for using independent console window
in different threads. It needs GT driver which supports such
functionality, f.e GTXWC in *nixes or GTWVT in MS-Windows
* harbour/tests/mt/mttest09.prg
! fixed typo in comment
* harbour/source/vm/thread.c
+ added small description for hb_threadOnce() .prg function
* harbour/include/hbthread.h
! do not set TLS in POCC and XCC builds when _MSC_VER macro is set
This compilers also have this macro but dllspec( thread) does
not work for them (at least in version 4.50.15)
* harbour/utils/hbtest/rt_hvm.prg
+ added few tests which exploit by DMC bug. Be careful with
this compiler. In some cases it gives buggy final code, f.e.
try this:
#include <stdio.h>
typedef struct
{
double dd;
long long int ll;
} UN;
const char * cmp( UN * pU )
{
return pU->dd >= pU->ll ? "OK" : "ERRROR";
}
int main( void )
{
UN u = { 10.50, 10 };
printf( "%s\n", cmp( &u ) );
return 0;
}
The same bug can be exploited also by final Harbour binaries
compiled by DMC in code like:
? iif( 10.50 >= 10, "OK", "ERROR" )
I used DMC 8.42n. As long as such things will not be fixed by
DMC developers this compiler is not supported by Harbour and
reported problems with DMC Harbour builds will have to be
ignored by us.
* harbour/source/vm/hvm.c
! execute hb_vmThreadQuit() after hb_vmStackRelease()
* harbour/source/vm/thread.c
* do not destroy critical sections on exit
* harbour/source/vm/hvm.c
* reduced the mutex lock time in thread exit state
* harbour/source/vm/thread.c
; added note about possible behavior of hb_threadSelf() function
in one very specific situation. It's documented and expected
behavior
* harbour/source/rtl/hbgtcore.c
+ added support for retrieving current HB_GTI_NOTIFIERBLOCK code block
+ added support for removing HB_GTI_NOTIFIERBLOCK code block without
setting the new one
* harbour/source/vm/garbage.c
* unblock HVM before executing destructors and releasing blocks
* harbour/source/vm/fm.c
! do not call internal error with active lock when FM statistic
is enabled
* harbour/source/vm/thread.c
! stop other threads in hb_threadOnce() if the 1-st one
executes bAction block to be sure that it will be completed
before thread leave hb_threadOnce() function
* harbour/source/vm/set.c
! do not call hb_inkeyReset() in set release. It's not necessary
and it could change keyboard buffer size for other threads using
the same GT driver.
* harbour/source/vm/hvm.c
% allocate new thread stack without lock
* harbour/source/rtl/hbgtcore.c
* harbour/source/rtl/gtapi.c
* moved clipboard resetting from hbgtcore.c to gtapi.c
* harbour/source/rtl/filesys.c
! do not use read/write operations with given file offset in Win9X
which seems to not support such functionality
* harbour/include/hbvm.h
* harbour/source/vm/hvm.c
+ added hb_vmProcessDynLibSymbols() which works like
hb_vmProcessSymbolsEx() but always mark registered modules as
dynamic
* harbour/source/vm/maindllp.c
* redirect hb_vmProcessSymbolsEx() to hb_vmProcessDynLibSymbols()
* harbour/source/vm/thread.c
* disabled some low level locking code in non MT HVM mode
* harbour/include/hbtypes.h
* harbour/source/vm/maindllp.c
! updated casting for current SVN code
[TOMERGE 1.0]
* harbour/include/hbthread.h
* harbour/source/vm/hvm.c
* harbour/source/vm/thread.c
+ added .prg function
hb_threadWait( <pThID> | <apThID>, [ <nTimeOut> ] [, <lAll> ] )
=> <nThInd> | <nThCount> | 0
This function wait for <nTimeOut> seconds (default infinite wait)
until one or all (controlled by <lAll> parameter) of given HVM threads
will have finished execution in HVM area. It does not join the threads.
It returns index to 1-st thread which has finished execution (default)
or number of threads which has finished in given time period when lAll
is .T.
* harbour/source/vm/hvm.c
! fixed last commit typo in thread number allocating - all threads
where using 0 number
* harbour/source/vm/thread.c
! fixed return value in recursive call to hb_mutexLock() - was FALSE
! fixed typo in timeout parameter number
should be 2 instead of 1
* harbour/source/rtl/tobject.prg
! fixed init() return value - it should be ignored and current
object should be returned
* harbour/source/rtl/tthreadx.prg
! probably fixed timeout parameter use in signal:wait() method
I guess that like other xbase++ functions it's in 1/100th of
a second
* harbour/include/hboo.ch
* harbour/include/hbclass.ch
* harbour/source/vm/classes.c
* harbour/source/rtl/tclass.prg
+ added support for SYNC object and CLASS messages working like
in xBase++. Please remember that all locked by thread SYNC messages
objects and classes are unblocked automatically for the time which
thread spends in hb_subscribe[Now]() or signal:wait()
* harbour/tests/speedtst.prg
* marked T054 as memory tests
* harbour/source/vm/hvm.c
* harbour/source/vm/thread.c
* added hb_threadOnce( @<onceControl> [, <bAction> ] ) -> <lFirstCall>
This function allow to execute some code only once. It's usefull in
MT environment for initialization.
<onceControl> is variable which holds the execution status and have
to be initialized to NIL. In most of cases it will be simple static
variable in user code.
<bAction> is optional codeblock which is executed only once (on 1-st
call with given <onceControl>)
* harbour/source/rtl/filesys.c
! do not make any file name conversions in hb_fsNameConv() if HVM stack
is not allocated
* harbour/source/rtl/gtcrs/gtcrs.c
* casting
