Actually it is to emulate weak references. Allocating the memory with malloc is an easy way to have references ignored by the GC. I have already written an improved version of std.signals. It already works, but the template mixin frontend for easy integration into a class (with private signal emission) is currently blocked by bug:
http://d.puremagic.com/issues/show_bug.cgi?id=8441 You can find my implementation at: https://github.com/eskimor/phobos/blob/new_signal/std/signals.d The current std.signals implementation does not support struct methods as slots, only objects. (Because only objects can notify when being deleted. (This is a documented bug, see: http://dlang.org/phobos/std_signals.html) My new implementation allows delegates of any type with strongConnect() but you will loose weak ref semantics. And you won't even be able to use connect() with anything else than an object, so the new implementation is not just more powerful, but also prevents from wrong use. You are actually a prime example, that documenting such things is not enough ;-) Best regards, Robert On Thu, 2013-01-17 at 23:33 +0100, David wrote: > Is there any reason why std.signals.Signal allocates with calloc and > realloc instead of using the gc directly? When digging through the code > everything seems magic and old. > > E.g.: > https://github.com/D-Programming-Language/phobos/blob/master/std/signals.d#L199 > > This looks like an old label used for a goto. > > (calloc/realloc: > https://github.com/D-Programming-Language/phobos/blob/master/std/signals.d#L170) > > Also rt_detachDisposeEvent and co. are magic to me, I can only guess > what they do when digging through the code, what prevents std.signals > from using the GC. It's just a guess but, I think this would also allow > the use of struct methods as callbacks. > > I ran into this issue today: > > --- > struct Foo { > Bar bar; > > void my_callback(int i) { > bar.do_something(); > } > } > > slot.connect(&foo.my_callback); > --- > > This kept segfaulting, chaning Foo to a class solves the issue. (I had > more such strange moments, using curry! together with a helper function > which bound the callbacks also introduced segfaults). > > I think that has to do with the manual memory managment used together > with the more or less magic functions. > > If you tell me that the manual memory management is an old D1 relict and > isn't needed at all, I could clean that code up and submit a pull > request (I really learned to like std.signals).
