----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3475/#review8349 -----------------------------------------------------------
Thanks for looking into this! Forking a multi-threaded simulation is very scary. If I remember my POSIX right, the behaviour after a fork of a multi-threaded program is undefined (IIRC, you are supposed to call exec without passing go and collecting $200). This is one of the reasons I didn't handle it when I originally implemented forking (and I didn't need it at the time). I would suggest that you instead make sure that all threads are joined before forking (e.g., by joining them after draining). - Andreas Sandberg On May 20, 2016, 11:11 p.m., Jason Lowe-Power wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3475/ > ----------------------------------------------------------- > > (Updated May 20, 2016, 11:11 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11483:d7066cc30459 > --------------------------- > sim: Fix fork for multithreaded simulations > > Previously, when forking, the thread states were inconsistent. > Now, after a fork, we re-create all the needed threads. > This allows you to run in *single-threaded* mode after a fork. > There would need to be a way to migrate the threads to conintue > in threaded mode. > > > Diffs > ----- > > src/sim/simulate.cc fc247b9c42b6 > > Diff: http://reviews.gem5.org/r/3475/diff/ > > > Testing > ------- > > > Thanks, > > Jason Lowe-Power > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
