wew, great, hats off!

I'll enable -mt in hbmk2 ASAP.
I'll also change its Makefile to always build with hbvmmt on DOS.

Brgds,
Viktor

On 2009.07.03., at 8:29, [email protected] wrote:

Revision: 11614
         
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=11614&view=rev
Author:   druzus
Date:     2009-07-03 06:29:26 +0000 (Fri, 03 Jul 2009)

Log Message:
-----------
2009-07-03 08:28 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
 + 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 x...@32 in DJGPP
Linux GCC and OpenWatcom builds. I tested OpenWatcom builds only in DOS and Linux but probably it works in all x...@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

Modified Paths:
--------------
   trunk/harbour/ChangeLog
   trunk/harbour/contrib/hbmzip/hbmzip.c
   trunk/harbour/include/hbatomic.h
   trunk/harbour/include/hbthread.h
   trunk/harbour/source/rtl/filesys.c
   trunk/harbour/source/rtl/idle.c
   trunk/harbour/source/vm/Makefile
   trunk/harbour/source/vm/fm.c
   trunk/harbour/source/vm/hvm.c
   trunk/harbour/source/vm/thread.c

Added Paths:
-----------
   trunk/harbour/include/hbtask.h
   trunk/harbour/source/vm/task.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to