Hi, 2009/7/8 Marcel Reutegger <[email protected]>: > - paralleled execution of some work. this is primarily to make use of > multi-core processors. execution should be distributed over and > executed by N threads which is a factor of the available processors.
If I recall correctly we debated this already earlier. My point was that limiting the number of tasks to the number of available processors may not be a good approach as the tasks may be IO-bound or block for other reasons, in which case having more task threads would give you better throughput. But I recall being proven wrong, did we have some benchmark for that? Do you remember where this discussion was? > - Timers used in TransactionContext and MultiIndex. This could be > turned into a scheduling mechanism that could also be used by the > ClusterNode sync. Other classes that use periodic checks in a > background thread: DatabaseJournal (ClusterRevisionJanitor), > CooperativeFileLock (watch dog). Yep. Perhaps we could also reuse some of the scheduling functionality in Sling. > the more I think about it, the more I like your idea. but we should be > careful with a maximum size for a repository wide pool. extensive use > of the pool by a module should not lock up another module just because > there are no more idle threads. maybe that global pool shouldn't have > a maximum size... That might make sense. Perhaps we should have some concept of sub-pools (that borrow from the main pool) with fixed limits for tasks that need them (see above). BR, Jukka Zitting
