This is done intentionally. The reason is to catch bugs, not to hide them. By overwriting the pointer, bugs in client code will be caught faster and caught in optimized code which is more likely to exhibit race conditions. It makes working with NetVCs much safer as it helps you find bugs in your code where you are not clearing all the pointers to the NetVC before calling close.
The core problem is that every crash will come out of the event, cache or network subsystems, because they generate the callbacks and the bug is 99% of the time in the client code, but client code writers like to blame the messenger so they are constantly trying to patch the event, cache and net system when the problem is theirs. In this case the API is really simple. Clear all pointers to a NetVC then call vc->do_io_close. Period. The problem is that someone is not doing that and then is shocked that the NetVC disappears after close is called. Adding a lot of baggage to the system and storing the NetVC pointers with smart pointers so that when someone forgets to clear a pointer they can still access the stale memory without crashing the system will result in subtle bugs. There is a bug and it needs to be fixed. We should not be wallpapering over water damage. Let's get to the root of the problem and fix it, not sweep it under the rug. john On Tue, Dec 13, 2011 at 8:10 AM, Alan M. Carroll < a...@network-geographics.com> wrote: > Another point on this issue is why the NetVC allocation scheme swizzles > the virtual function pointer, rather than having a separate pointer for the > free list. This makes working with the NetVCs far more dangerous and I > don't see what the benefit that justifies this risk is. Is there any > possibility of changing this back to be in the same style as the intrusive > linked list? > >
