Re: mem leaks win32 call_back
- Posted by jimcbrown (admin) Feb 06, 2010
- 1155 views
OK, so for callbacks in general: When would you free them? Why?
Sorry, maybe I missed it, or just not getting it. This is an honest question about how you would decide to free a callback. In what sort of situation would this be useful? If there's a good reason for it, it's definitely something we could do.
But it would complicate the code, add places for us to write bugs, etc, and I just can't justify it, because it seems like something that's likely unsafe, and doesn't really do all that much for you. I'd be happy to be shown to be wrong here, though, because maybe there is something cool that can be done with it.
Well, technically, we are leaking memory with callbacks ... even if we only make a callback to be used once, and called once, say for initialization of a library at program startup, the memory stays used until the process ends. I do not find the argument that freeing a callback might be unsafe to be very compelling, as the same applies to freeing memory in general - and in fact to using define_c and c_proc/c_func.
Projects in other languages which have thousands of functions do exist, and being able to generate callbacks arbituarily (without having to worry about memory usage in worst-case scenarios) would be quite handy.
Also, as raseu points out, the current system limits the design of end user code. He or she has to redesign his code to use a table to remember routine ids and if a callback already exists for it (although this could also be fixed by having the backend store and remember the callback, so there is only one callback ever created for one routine id).
Another reason is portability.. moving away from ftpr.e (which in any case seems like overkill just for the ability to free callbacks) means no need to rewrite machine code for a different arch.
The above directly contradicts the next reason, however, which is to allow for directly modifying the callback machine code. Once the end user has copied the machine code over and manipulated it, it would be handy to be able to free the original when it is no longer needed.
I haven't looked closely at the changes Shawn recently made, but I suppose there's no reason why we couldn't recycle the memory used for callbacks.
From his comments, the impression I got was that we had to choose between two options. So it would not be possible to free callbacks without reverting some of his changes..
