On Wed, Feb 23, 2011 at 5:03 PM, Gabe Black <[email protected]> wrote:
> Forgive my ignorance here, but why is the limit event set up each time > simulate is called? Couldn't it just be a member of the event queue > class and always stuck at the end and left there? > The limit can change from call to call, and it's not necessarily the last thing on the queue, so you do have to at least reschedule it between calls to simulate(). On Wed, Feb 23, 2011 at 5:25 PM, nathan binkert <[email protected]> wrote: > Though you can't make an exit_event AutoDelete because the event needs > to be returned to python. So holding onto it and reusing it between > simulate() calls is probably the correct thing to do. > That's one approach. Another is to not pass the event itself back to python, but to create a new class like SimExitCause that's something like a python exception class, and pass a dynamically allocated instance of that into exitSimLoop() instead of a string and a code. Then we can autodelete the event but somehow pass the SimExitCause instance back. The method for getting that instance out of the event and back up to the simulate() loop for returning to python is not clear to me though, so maybe this is not a better idea. Just brainstorming. As far as the parallel queues goes, I did rewrite a bunch of this code, so it'd be nice not to make big changes at this point. If they're simple, though, I can easily just add the comparable change to my patch. I think the big thing standing in the way of checking my patch in is that I just use pthreads calls directly, and I think we at least want to provide some way of not requiring pthreads if you're not doing parallel simulation. We also may want to abstract that out to allow other threads packages (if there are any that would be useful to support). Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
