On Tue, 14 Oct 2008, Szak�ts Viktor wrote:

Hi Viktor,
[...]
> When I turned off debugging, the problem went away.
> If you want, I can redo some tests to make the
> circumstances cleaner.

I'll look at it. If I will not be able to isolate the
problem then I'll ask you for help.

>> TODO:
>>   1. We should check contrib code and eliminate non MT safe code
>>      or document non MT safe functions.
>>   2. Possible TODO: make RDD settings (rddInfo()) thread local.
>>      Should we make it?
> IMO, it should be global. But I couldn't find
> any detailed documentation on this function. We have

I was documenting some RDDI_* actions in xHarbour ChangeLog.
Just like many other RDD extensions. If someone can collect
them in one peace of documentation then it will be nice.

> to take into account though, that some externally
> dependent RDDs may not support multiple configurations per
> thread, also I'd think this would lead to chaos
> in real life, and overkill flexibility and source
> of bad problems.

Some features can be usable as thread local. F.e. I may want
to change default index extenssion only in one thread.
Or I may want to use multitag NTX indexes with large file support
(upto 4GB) and recono as hidden part for index key (just like in
CDX and NSX) but in other threads I may want to use standard NTX
format.
If RDD will not support thread local settings then they will be
global. It's enough to document it. It's even possible that they
will mix some settings and some of them will be thread loacl and
some others globals, f.e. when they are for global resources.
Just like in current SETs. If two threads shares GT window (now
all threads shares GT window) then SET COLOR or SET TYPEAHEAD
effects shared resource and effectively is shared between threads.

>>   3. Thread priorities - is it really necessary?
> IMO, it would be useful. No real life personal need
> yet from my side, but I could imagine using IDLE
> initially, and maybe even more levels for a server-side
> app.

In the moment when you run thread with higher then normal priority
you can kill multitasking. To make it weel you have to know what
exactly priority modification will cause. There are three main
settings which change thread priority:
   1. The frequency of giving CPU time
   2. The length of periods with CPU time
   3. The priority in critical sections
Additionally there are also guaranties that thread will receive CPU
time and that it will be taken of in some period.
In some OSes they can be controlled separately in some other not
and here the 3-rd point above is danger sometimes. Many OSes gives
unconditionl preference to thread with higher priority so they can
practically stops all other threads execution when they have to
use common critical sections. It's also the problem how to create
Harbour API which will hide differences between OSes. Only IDLE
priority can have the same meaning in all OSes. Other will introduce
some more or less important differences.

best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to