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@alexrp.com / alex@lycus.org
http://lycus.org

Am 20.01.2013 12:25, schrieb Robert:
> Of course. Just at the moment issue: http://d.puremagic.com/issues/show_bug.cgi?id=8441
> 
> is holding it back.

Bugs, as usual.

> It will be probably named std.signals2 or something to maintain backwards compatibility, but yeah I definitely want to get it into phobos. In fact, I don't even have a use for it in my own projects, I just saw the current implementation and thought there must be a better way. So the whole point of implementing it, was to get it into phobos.

Good news.


> I strongly encourage you to use my implementation, because real world testing before becoming a part of the standard library is always a good idea. But keep in mind, that it wasn't formally reviewed yet so your code might break, when being included into phobos. (Stuff might get renamed for example.) On the other hand fixing this issues should not be too much work. So yeah, please try it out, so it will be perfect when included. The feature set and set of improvements, should be convincing anyway, if not I have done something wrong.

I can't do that, I am using std.signals in a library and I wanna keep it as small as possible.