Przemyslaw Czerpak wrote: > 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
Ok, this goes to the programmer responsability, I can kill a system in a lot of ways as soon as I start writing something :) > 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 And to hide this complexity we create some high level definitions, that simply guarantee to the harbour programmer that a higher priority will get more 'power' from the system. It will be his/her care to be sure that his/her program is not killing the receiving OS. > 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. > Ok, so let's say we have PRI_IDLE, but as soon as we can go down a step we need a way to go up a step to return to the regular class of priority and so we have PRI_REGULAR. Now, we could stop here and, as you say, this could cover 99% of all needs. I say that we could have a third level, which is PRI_TIMECRITICAL (or any other name) which gives a boost over PRI_REGULAR (for those cases... let's say a thread to read a serial port). I think that such a three levels system would be ok for every real need (apart from some fancy cases, which can be solved by each programmer writing some C code). Sincerely. Maurilio. > best regards, > Przemek > _______________________________________________ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __________ | | | |__| Maurilio Longo |_|_|_|____| farmaconsult s.r.l. _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
