std.signals and malloc

[eskimo]

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).