MessagePort: implemented virtual recvTiming avoiding double delete
Review Request #382 - Created Jan. 6, 2011 and submitted
|ali, gblack, nate, stever|
MessagePort: implemented virtual recvTiming avoiding double delete Double packet delete problem is due to an interrupt device deleting a packet that the SimpleTimingPort also deletes. Since MessagePort descends from SimpleTimingPort, simply reimplement the failing code from SimpleTimingPort: recvTiming.
Posted (Jan. 6, 2011, 8:21 p.m.)
I think there are two problems with this patch. First, if at all possible we should avoid the code duplication we'd now have for the recvTiming function. Second, while this probably does fix the legitimate problem of deleting packets twice, I think it creates a memory leak in the process. I suspect if you leave your other changes in place but get rid of your custom recvTiming function, things will still work. The packet won't be deleted by the device, won't be deleted after being received as a request in either atomic or timing mode, but will be deleted in both modes after being received as a response. The "virtual" you added in tport.hh could almost certainly go away then too.
src/mem/mport.cc (Diff revision 1)
I really don't like how much code duplication there is now between these two classes.
src/mem/tport.hh (Diff revision 1)
Marking this as explicitly virtual shouldn't really be necessary. Is there a reason you want to?