Quoting Steve Reinhardt <[email protected]>:
I don't think I changed anything here... hg annotate seems to back me up on that, too. I think the fundamental (but subtle) issue here is that once you successfully send a packet, the ownership for that packet object is conceptually handed off to the recipient, so technically the sender shouldn't be dereferencing that packet pointer anymore. Thus it's OK for Ruby to push its own senderState into the packet if it wants. If I had to guess I think it might just be that Gabe hasn't been testing with Ruby...
Yes, that's probably true. Mercurial backs you up, but I honestly don't remember writing that code. Old age I guess :-).
(That said, looking over the Ruby code with fresh eyes after not having thought about it for a while, I think the Ruby code might be overcomplicated... instead of only tracking the m5 packet pointer in the ruby request object, then using senderState to look up the port based on the packet, why don't we just keep the both the packet and the port in the ruby request?) At a high level I think part of the issue with the sendSplitData() code is that buildSplitPacket doesn't return a pointer to the "big" packet, so the only way to access it is via the senderState objects of the sub-packets. I expect that with some thought we could restructure the code to be a little cleaner, but Joel's idea of holding on to the original senderState pointers on the stack seems like a reasonable interim solution.
That sounds reasonable. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
