Compatibility Break Discussion
pRED and I are mulling over adding a garbage collector to SourceMod. This thread is NOT about whether that's a good idea. What it is about is that it would potentially break extension compatibility, and we'd like input from extension developers.
To GC handles we'd need extensions to implement two functions: 1) For composite handle types (handles that can reference other handles), a callback that asks the IHandleType implementation how to walk the object's memory. 2) For IExtensionInterface, a callback that notifies SourceMod of any Handles being held onto in places it can't see - for example, if your extension has a list of callbacks with "any:data" user values, it would need to inform SourceMod about those. For example, the code to PJ's SHVector extension would need to walk open vectors and inform SourceMod about each value that is potentially a handle. If you don't have composite structures, this change is trivial - but it would still break compatibility. In order to get this feature in extensions must use the new API. Otherwise we would have to scan the entire process memory. In worst cases, we would fix all third party extensions. Nevertheless, I'm interested in how everyone feels about this. Do you think this is a reasonable change? Do you think you'd be able to update your extension? Do you have any questions or thoughts? This idea is still nascent, but the API would look something like this... IHandleType changes: Code:
+Code:
/**Code:
+ /** |
Re: Compatibility Break Discussion
Quote:
|
Re: Compatibility Break Discussion
Im no coder by any means, but what would be the purpose for this "garbage collector" that would break all these extensions?
Just curious. :) |
Re: Compatibility Break Discussion
I think there's such a low amount of third party extensions that would indeed be trivial to fix them. Some of them (Hacks, Hooker, DukeHacks) can even be deprecated and turned into one big hooks extension.
|
Re: Compatibility Break Discussion
Xp3r7: It is a feature for developers that allows them to not worry about leaking memory.
|
Re: Compatibility Break Discussion
Quote:
|
Re: Compatibility Break Discussion
Quote:
Quote:
I would really like to see this implemented. |
Re: Compatibility Break Discussion
Quote:
Please - this thread is for extension developers. |
Re: Compatibility Break Discussion
So would this break every SourceMod extension?
|
Re: Compatibility Break Discussion
Imagine the following code which contains a clear runtime error:
PHP Code:
1. terminate operation for the specific socket object 2. remove all queued callbacks 3. call something like InvalidateHandle(Handle_t x) InvalidateHandle must invalidate the handle instantly to make SocketSend in someOtherFunction() throw an error when ReadHandle fails. In the next GC run (which shouldn't be too late) OnHandleDestroy frees all resources attached to the specific socket. The socket extension will report all alive socket handles in IExtensionInterface::OnTraceHandles through ITraceHandler::Trace. All data arguments will be reported in IHandleType::OnTraceHandle with ITraceHandler::MaybeTrace. I also need a legacy interface for old scripts to process CloseHandle similar to the new CloseSocket. edit: Note that MySocket is global and therefore doesn't drop the reference to the handle, but the Handle should be collected after InvalidateHandle anyway. |
Re: Compatibility Break Discussion
An optional argument for handlesys->CreateType to specify the approximate overhead (memory allocated by the extension) per handle could be useful for the GC to determine the actual memory usage.
|
Re: Compatibility Break Discussion
sfPlayer: Good idea, that could avoid some perf hits if a general, mostly accurate size of handles is known at creation time.
|
| All times are GMT -4. The time now is 18:49. |
Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.