std.signals and malloc

[Alex Rønne Petersen]

On 17-01-2013 23:33, 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).
>

rt_attachDisposeEvent() just attaches a destructor to an object. It 
allows you to build a list of delegates that will be called when the 
object is destroyed. It's basically just a way to have multiple 
destructors on a single object.

-- 
Alex Rønne Petersen
alex at alexrp.com / alex at lycus.org
http://lycus.org