> It's a flexibility/fear-of-commitment thing... initially I wasn't positive > which way I would go, and once I decided that > curTick-as-EventQueue/Manager-field wasn't going to work well (too many > places where it's pretty awkward to find the object pointer), I figured it > would still be useful in case we need to use pthread_setspecific/getspecific > on some platforms (OS X? OpenBSD? Cygwin?). Makes sense.
> I also kind of like how it indicates that curTick is not a "normal" > variable... implicitly declaring it as part of TLS in one file without any > indication at each reference that it's different seems potentially > confusing. Good point. > Why do you say that? Because you could put the EventQueue pointer in TLS > too and not do the object-based lookup? I think it would be useful to check > that the EventManager queue pointer and the TLS queue pointer are the same. Sounds good. >> TLS scares me, but maybe that's unnecessarily. :) > Why? Because it's essentially global variable with somewhat complicated semantics, but if it's hidden, I'm cool. > I haven't gotten that far yet, but yes, something like the locked external > queue with async polling was what I was thinking of so far. I've been > approaching it more top-down: what should simulate() look like, how do we do > initialization, etc. Cool. I should dig up my code. > Sure, I've got some time today late morning & early afternoon if you're > free. I'm in a meeting that will end in the next 15 mins to half hour. After that I've got nothing. Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
