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