Re: mem leaks win32 call_back
- Posted by mattlewis (admin) Feb 07, 2010
- 1137 views
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.
I guess something that's guaranteed to only be called once, like for initialization is a good example of something that could be freed safely. I was thinking of what I believe is the main use of a callback, which is used in conjunction with GUI libraries as ways for the OS/window manager/etc to send messages to the user's program. About the only time it's safe to free that sort of callback is at the end of your program. Maybe some timer callbacks (assuming it even gets its own callback) are throw aways.
But maybe raseu is doing something completely different. That's what I'm interested in finding out. I guess I view this leaked memory in a similar manner to having messages sitting around in RAM. In fact, strings stored in constants probably take up way more memory in a typical program than the callbacks. Especially than callbacks for things like initialization.
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.
Maybe. An example would be much more persuasive.
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).
Yes, that's probably the obvious next step. But I still think we need a better case made for doing something like this.
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..
It depends on the platform. On windows, we're allocating chunks of memory (page size, I think) due to the way we have to protect the memory. I suspect we should probably be doing that on other platforms, too. So in that case, we've got a custom malloc process where we could, in theory, add an ability to recycle old callbacks that are no longer required.
This all just seems like so much premature optimization though.
Matt
