On Tue, Oct 14, 2003 at 09:29:11AM +0200, Niklas Bergh wrote: > > So, last night toad added code that enables fred to treat some TickerEvents > as "fast events".. "Fast events" are executed on the thread that tries to > schedule them instead of on a Thread from the Pool, effectively throttling > unnecesary thread creation and removing some unnecessary scheduling > overhead. An obvious side effect of this mechanism is that this the thread > that wants to schedule an event might instead end up executing it, beeing > blocked during the time the execution consumes. Hence the name "fast > events"... we should avoid executing anything that isn't "fast" on the > scheduling thread. Unfortunately, today, it has proved that bucketloads of > "fast events" still consumes significant amounts of execution time and > since, in the current architecture, the threads ending up executing the > bucketloads of "fast events" are the *SL threads.. the network communication > threads.. thereby blocking network communication more than desired.
Well, the "fast events" in question evidently weren't that fast. That is a bug. Can we try to fix the bug before adding bucketloads of overhead back in for them? > > I am about the commit a change that enables the Ticker to take a middle > route between the old behaviour and the new one. I am adding a thread, > internal to the Ticker, that is dedicated to handle all of these "fast > events", thereby relieving the scheduling thread of the execution but still > not causing the ThreadPool to spawn large amounts of threads to execute > these "fast events". This thread will have a maximum allowed backlog, when > the backlog is full the Ticker will revert to letting the scheduling thread > execute the event (the current queue size and the actual events can be seen > in a separate table in the 'Pending Tasks' infolet). See above. > > This graph indicates the effect of this change on network bw usage (before > change is to the left, after is to the right): > http://194.236.28.174/freenetstuff/6237_and%206237modified_bwusage.jpg Cool. Does not invalidate what I said above though. > > /N -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
