Products

Price/Order

Support

Partners

Testimonials

Test Results

About us

Contact
 Setting thread priority
Bottom
 
Total posts: 3
 Author Setting thread priority
Rik Halfmouw

18.09.2007 16:41:59
Registered user
Is it possible to set the priority of the request thread when using a multithreaded rtcHttpServer ?
I would like to post a job to the server to perform a CPU intensive update task at a lower priority so it won't interfere with other requests to the server
Danijel Tkalcec [RTC]

18.09.2007 20:46:28
Registered user
Since RTC SDK uses a thread pool and all threads have the same priority, you could lower or raise the priority of all threads by setting the "RTC_THREAD_PRIORITY" variable in the "rtcThrPool" unit - on app start.

If you need to have a specific task running in a separate thread, you can always create the thread yourself (TThread class).

Best Regards,
Danijel Tkalcec
Danijel Tkalcec [RTC]

19.09.2007 19:00:49
Registered user
In general, I wouldn't go about changing thread priority of a long-running thread, since one client processing data would not BLOCK other threads, it would only make them slower (sharing CPU time equaly across all threads). So, requests from other clients would still be processed.

Lowering thread priority from one long-running thread would give more CPU time to other threads, but it would also stretch out the time which your long-running process needs to complete. If that process has been started from a Client, that Client would also like to get a result sometime soon - before the connection breaks.

Anyway ...

I am now considering to add a property to TRtcConnection objects, which would allow you to temporarily change the priority of the thread in which your event is being executed. That would allow you to have your code run in a higher or lower priority than other RTC threads, simply by changing a property inside the event.

Thread Priority would automatically return back to default when your event is done executing, so there would be no consequences to other connections getting the same thread from the pool after you are done, even if you forget to reset the thread priority before event ends.

Naturally, changing the Thread Priority inside the event would only make sense in case you expect your code to run for longer and do not mind if that processing would be stretched out every time a request comes from another client. Changing thread priority in short events which would execute for a few nanoseconds would not make much sense, as it would only slow your application execution - consuming CPU time to change thread priorities.

Regards,
Danijel