Compliment Genius
Can i give you some little clarification regarding "multi windows interface for
thread "
TODO: CTWIN is not MT safe yet - it will be updated together
with core GT when we add multi window interface for
thread with own console window.
I admit that I have same project where "multi windows" will be very useful
How a clipper developer can help you?
Can I help you collecting post regarding MT and sending you for using as basis
for documentation?
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Przemyslaw
Czerpak
Sent: Monday, September 22, 2008 2:46 AM
To: Harbour Project Main Developer List.
Subject: [Harbour] MT TOFIX / TODO
Hi all,
Here is a list of things which should be fixed or added
in Harbour MT mode. I plan to make most of them soon but
I think it's good to document them now to avoid possible
problems or confusions.
In few cases I do not know if I will want to resolve them
for MT mode, f.e. investing time in MT safe profiler code.
Maybe I'll simply always disable it in MT builds.
1. Tracelog is not MT safe
BTW: By default HVM is compiled with optional .prg function call
tracing. This feature can be controlled (enabled/disabled) by
__TRACEPRGCALLS() function. If user does not want to use it
then he can rebuild Harbour with HB_NO_TRACE.
IMHO HB_NO_TRACE should be default for Harbour builds and user
who need it should recompile Harbour with HB_PRG_TRACE.
I plan to make it soon.
2. DEBUGGER is not MT safe. Now do not use debugger in code with
more then one thread active or it will crash.
Before we will touch this code please think how MT debugger should
work.
3. PROFILLER is not MT safe. It's optional code disabled by default.
Before we will touch it please think how it should work for MT
programs.
4. There is possible race condition in hb_threadWaitForAll() and
hb_threadTerminateAll() - it's possible that they will finish
and new HVM thread will be created in a while. It may happen
when one of child thread begin to starts new thread and then is
terminated. Both functions can finished waiting for loop for
existing threads before the new one will be registered. It
has to be fixed and I'll make it ASAP
5. hb_threadQuitRequest() can be ignored by thread in some cases
due to race condition. It may happen if thread will overwrite
request send by caller simultaneously, f.e. by BREAK.
6. There is possible race condition when class function is
called 1-st time to create new object. It's possible that
two threads will try to register the same class. It has to
be fixed.
7, HB_LIBLOAD()/__HRBLOAD() may not be MT safe in some cases.
Before they will not be resolved please try to not use this
functions when other threads are executed.
8. It will be good to add user functions to resize class and RDD
node arrays for situation when user will want to use more classes
or RDDs registered at runtime by threads then set by default.
9. We should use hb_vmUnlock()/hb_vmLock() with hb_vmRequestQuerry()
checking inside hbinet.c
10. Add protection for single GT access from different threads.
11. We need our own file lock server for aliased and MT workareas
synchronization in POSIX systems
12. We should check contrib code and eliminate non MT safe code
or document non MT safe functions.
best regards,
Przemek
_______________________________________________
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
