One addition to previous mail:
In MT mode (even if there is only one job), HB_COMPILE()
is launched in a separate thread in hbmk2.
(I'll change hbmk2 to do it in current thread, that's pbly
better for performance.)
Brgds,
Viktor
On 2009.07.03., at 13:25, Viktor Szakáts wrote:
Hi,
When trying to use DJGPP MT build of hbmk2, it GPFs
inside HB_COMPILE() call:
[ it works when using -hb10 to force using external harbour.exe
for compilation. It also works with non-MT build of DJGPP hbmk2.exe. ]
---
C:\hb2b2dj\bin>dj hbmk2.exe hello.prg
Setting environment for using DJGPP 4.3.2
hbmk: Processing configuration: c:\hb2b2dj\bin\hbmk.cfg
Harbour 2.0.0beta2 (Rev. 11614)
Copyright (c) 1999-2009, http://www.harbour
-proje
ct.org/
Exiting due to signal SIGSEGV
General Protection Fault at eip=0010c7e7
eax=2072756f ebx=001f18b0 ecx=001f1910 edx=20727573 esi=001f1910
edi=00000005
ebp=001eead8 esp=001eeacc program=C:\HB2B2DJ\BIN\HBMK2.EXE
cs: sel=01a7 base=029e0000 limit=001fffff
ds: sel=01af base=029e0000 limit=001fffff
es: sel=01af base=029e0000 limit=001fffff
fs: sel=017f base=000076d0 limit=0000ffff
gs: sel=01bf base=00000000 limit=0010ffff
ss: sel=01af base=029e0000 limit=001fffff
App stack: [001c8664..00148664] Exceptn stack: [001485a8..00146668]
Call frame traceback EIPs:
0x0010c7e7
0x000b6511
0x000aec09
0x0005ba28
0x0005e055
0x000225fa
---
Brgds,
Viktor
On 2009.07.03., at 8:29, dru...@users.sourceforge.net 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
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
