> _tab.closed.connect((sender,args)=>this.Dispose()); > > If the closure dies prematurely, it won't free resources at all > or at the right time. Although you currently keep a strong > reference to closures, you claim it's a bug rather than feature. > You fix deterministic sloppiness of memory leaks at the cost of > undeterministic sloppiness of prematurely dying event handlers > (depending on the state of the heap).
Now I see where this is coming from, you got that wrong. It is an absolute must to have a strong ref to the closure. Otherwise it would not work at all, but the signal should not keep "this" from your example alive, which is obviously not possible, because it would break the closure, also the signal has no way to find out that this.Dispose() is eventually invoked. The trick that solved both problems is that I pass the object to the delegate, instead of hiding it in its context. This way I don't have a strong ref from the delegate, which would keep the object alive and the signal can tell the runtime to get informed when the connected object gets deleted. The thing I claimed a side effect (not a bug, it really is not) is that you can create a strong ref to the object easily, by issuing connect with null for the object and simply contain the object in the delegates context. This way also struct methods and other delegates can be connected to a signal, but with strong ref semantics. Maybe this misunderstanding was caused by this thread unfortunately being split up in two threads, so you might have missed half of my explanation and examples: One is starting with "std.signals2 proposal" and one staring with "RE: std.signals2 proposal". Best regards, Robert
