Hi Beyers, On 5/17/11 2:14 PM, Beyers Cronje wrote: > Hi, > > I've been toying with multithreading in click, specifically in userlevel > click. My understanding is that all click threads participate in running > timers and os (selected etc).
Yes, that's right. > I'm thinking about testing something where a > user can specify that certain threads should not participate in any timers > or selected processing and only process task(s) allocated to it. As a simple > example consider the following userlevel config: > > fd::FromDevice(eth0) -> Classifier(*some pattern*) -> Queue -> > td::ToDump(/dev/null); > StaticThreadSched(fd 0, td 1); > > > If FromDevice or whatever source element processes a constant high packet > rate, and ToDump only a fraction of packets as filtered by Classifier it > would make sense to have fd dedicate to processing RX packets and have the > td thread handle all other non-task related processes. Throw in a > ControlSocket and maybe a couple more dumps I'm pretty sure it will affect > fd performance. > > So my question, do you guys feel this will make any difference? Is my > understanding on how RouterThread handles timers etc wrong? I'm really > curious to hear your thoughts on this. I think this is a potentially interesting direction to move. Eventually, though, I want this to move in a different direction, in which selected file descriptors, timers, and even handlers are handled by threads *the same way as tasks*. That is, if StaticThreadSched(td 1) is given, then td's Timer/selected/etc. will be handled by thread 1. This would simplify reasoning about multithreading interactions. Currently we have, for example, selected() operations and timers that emit packets -- but that can cause problems if the timer runs on a different thread from the associated task. Make sense? Eddie > > Beyers > _______________________________________________ > click mailing list > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
