Thread Scheduling

[Milian Wolff]

Milian Wolff, 14.12.2010:
> Hey all,
> 
> Till Adam just gave me some comments on a few internals of KDevelop. He
> dived into the code to investigate the ForegroundLock (which he finds to
> be a very "interesting" idea). Anyways - in his opinion KDevelop has a
> huge issue with thread scheduling, esp. of IO intensive jobs. For example
> we have the background parser using two or more threads. Then cmake uses
> QtConcurrent with $ideal-thread-count more threads. All of those are IO
> intensive and can easily starve each other, so I understood him.
> 
> This is probably a hard task to solve, or even to investigate. Has anyone
> got any good reads on this topic for me? Or any hints on how to debug /
> profile / ... this?
> 
> Bye

This could be solved quite easily imo by using ThreadWeaver everywhere.

We could make the global threadweaver public and add jobs there as required. 
Using ResourceRestrictionPolicy we could cap all potentially IO-demanding jobs 
to a global total. The question is: what would be a good number for the cap? 
2? We could also make project-import-jobs higher priority then parse jobs. Oh 
and find-replace jobs should also use ThreadWeaver as they are of course IO 
intensive as well. They could be of highest priority since they potentially 
change contents.

What do you think?
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20101214/19824b10/attachment.sig>