View mode: basic / threaded / horizontal-split · Log in · Help
January 20, 2013
Re: std.signals and malloc
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
January 21, 2013
Re: std.signals and malloc
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.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home