View mode: basic / threaded / horizontal-split · Log in · Help
April 14, 2013
Is there any plans to make working signals in D?
For "working signals" I suppose will be enough fixing of both Issue 9606 
[1] and Issue 9603 [2].

IMO, for the first issue we need weak references [3].
IMO, for the second issue we need to make regular D objects on closures 
[4] and fix Issue 9602 [5].

Any thoughts about my proposal to make signals working in D? Other 
proposals? Any (approximate) period for [proposal parts] to be implemented?

Also, does anybody think currently D has working signals and I'm just 
slander in the title?

P.S.
Also there is a proposal for new signals implementation without compiler 
changes [6].


[1] http://d.puremagic.com/issues/show_bug.cgi?id=9606
[2] http://d.puremagic.com/issues/show_bug.cgi?id=9603
[3] http://d.puremagic.com/issues/show_bug.cgi?id=4151
[4] http://d.puremagic.com/issues/show_bug.cgi?id=9601
[5] http://d.puremagic.com/issues/show_bug.cgi?id=9602
[6] http://d.puremagic.com/issues/show_bug.cgi?id=9347

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
April 14, 2013
Re: Is there any plans to make working signals in D?
There is: http://wiki.dlang.org/Review_Queue

It is currently blocked by:
http://d.puremagic.com/issues/show_bug.cgi?id=8441

There is already a pull request for 8441, but it was not merged yet.

As soon as 8441 gets fixed, I am going to finish up the implementation
to make it ready for review.

For an overview of fixes and improvements over the current
implementation, simply search the forums for std.signals2.

Best regards,
Robert

On Sun, 2013-04-14 at 11:06 +0400, Denis Shelomovskij wrote:
> For "working signals" I suppose will be enough fixing of both Issue 9606 
> [1] and Issue 9603 [2].
> 
> IMO, for the first issue we need weak references [3].
> IMO, for the second issue we need to make regular D objects on closures 
> [4] and fix Issue 9602 [5].
> 
> Any thoughts about my proposal to make signals working in D? Other 
> proposals? Any (approximate) period for [proposal parts] to be implemented?
> 
> Also, does anybody think currently D has working signals and I'm just 
> slander in the title?
> 
> P.S.
> Also there is a proposal for new signals implementation without compiler 
> changes [6].
> 
> 
> [1] http://d.puremagic.com/issues/show_bug.cgi?id=9606
> [2] http://d.puremagic.com/issues/show_bug.cgi?id=9603
> [3] http://d.puremagic.com/issues/show_bug.cgi?id=4151
> [4] http://d.puremagic.com/issues/show_bug.cgi?id=9601
> [5] http://d.puremagic.com/issues/show_bug.cgi?id=9602
> [6] http://d.puremagic.com/issues/show_bug.cgi?id=9347
>
April 14, 2013
Re: Is there any plans to make working signals in D?
14.04.2013 15:22, Robert пишет:
> There is: http://wiki.dlang.org/Review_Queue
>
> It is currently blocked by:
> http://d.puremagic.com/issues/show_bug.cgi?id=8441
>
> There is already a pull request for 8441, but it was not merged yet.
>
> As soon as 8441 gets fixed, I am going to finish up the implementation
> to make it ready for review.
>
> For an overview of fixes and improvements over the current
> implementation, simply search the forums for std.signals2.

Does it mean you disagree with proposed compiler changes and with the 
idea we have to create weak reference functionality instead of 
recreating it every time it is needed (beside of theoretical danger such 
approach already showed it as a bad thing with `std.stdio.File` as I wrote)?

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
April 14, 2013
Re: Is there any plans to make working signals in D?
> Does it mean you disagree with proposed compiler changes and with the 
> idea we have to create weak reference functionality instead of 
> recreating it every time it is needed (beside of theoretical danger such 
> approach already showed it as a bad thing with `std.stdio.File` as I wrote)?
> 


A weak reference could actually be implemented in the library relatively
easy. ( I basically did it for std.signals2 ) But for std.signals a weak
ref is not really enough, because ideally the slot gets removed if the
target gets destroyed, not only set to null. Updating a collection on
destruction of an object is not that easy as you pointed out (thank you
for that), but I don't see how weak references would help there.

But you just made me think: If it is ok that a signal does not release
the memory for the slot immediately when the object gets destroyed but
only on the next call to emit(), then the implementation would be much
simpler ...

Best regards,
Robert
April 14, 2013
Re: Is there any plans to make working signals in D?
Am Sun, 14 Apr 2013 19:07:58 +0200
schrieb Robert <jfanatiker@gmx.at>:

> > Does it mean you disagree with proposed compiler changes and with
> > the idea we have to create weak reference functionality instead of 
> > recreating it every time it is needed (beside of theoretical danger
> > such approach already showed it as a bad thing with
> > `std.stdio.File` as I wrote)?
> > 
> 
> 
> A weak reference could actually be implemented in the library
> relatively easy. ( I basically did it for std.signals2 ) But for
> std.signals a weak ref is not really enough, because ideally the slot
> gets removed if the target gets destroyed, not only set to null.
> Updating a collection on destruction of an object is not that easy as
> you pointed out (thank you for that), but I don't see how weak
> references would help there.
> 
> But you just made me think: If it is ok that a signal does not release
> the memory for the slot immediately when the object gets destroyed but
> only on the next call to emit(), then the implementation would be much
> simpler ...
> 
> Best regards,
> Robert
> 

IMHO if a object still is connected to a active signal it should not be
collected. So the place where the signal stores the handler should be
scanned by the GC as usual. Then just document clearly that you have to
remove a handler to make sure that garbage collection can really kick
in.
April 14, 2013
Re: Is there any plans to make working signals in D?
> IMHO if a object still is connected to a active signal it should not be
> collected. So the place where the signal stores the handler should be
> scanned by the GC as usual. Then just document clearly that you have to
> remove a handler to make sure that garbage collection can really kick
> in.

If you really want this behaviour, all you need is an array of
delegates. But in my experience you don't usually want that, because
you would have to take care of dropping any connections by hand, which
is even more cumbersome than manual memory management in some regards.

Best regards,
Robert
April 14, 2013
Re: Is there any plans to make working signals in D?
On Sunday, 14 April 2013 at 17:35:00 UTC, Johannes Pfau wrote:
> IMHO if a object still is connected to a active signal it 
> should not be
> collected. So the place where the signal stores the handler 
> should be
> scanned by the GC as usual. Then just document clearly that you 
> have to
> remove a handler to make sure that garbage collection can 
> really kick
> in.

The caller should have the option to connect a strong reference 
or a weak reference. In C#, people forgetting to disconnect event 
handlers is the most common source of memory leaks. Let's not 
bring that to D.
April 15, 2013
Re: Is there any plans to make working signals in D?
On Sunday, 14 April 2013 at 07:06:12 UTC, Denis Shelomovskij 
wrote:
> For "working signals" I suppose will be enough fixing of both 
> Issue 9606 [1] and Issue 9603 [2].
>
> IMO, for the first issue we need weak references [3].
> IMO, for the second issue we need to make regular D objects on 
> closures [4] and fix Issue 9602 [5].
>
> Any thoughts about my proposal to make signals working in D? 
> Other proposals? Any (approximate) period for [proposal parts] 
> to be implemented?
>
> Also, does anybody think currently D has working signals and 
> I'm just slander in the title?
>
> P.S.
> Also there is a proposal for new signals implementation without 
> compiler changes [6].
>
>
> [1] http://d.puremagic.com/issues/show_bug.cgi?id=9606
> [2] http://d.puremagic.com/issues/show_bug.cgi?id=9603
> [3] http://d.puremagic.com/issues/show_bug.cgi?id=4151
> [4] http://d.puremagic.com/issues/show_bug.cgi?id=9601
> [5] http://d.puremagic.com/issues/show_bug.cgi?id=9602
> [6] http://d.puremagic.com/issues/show_bug.cgi?id=9347

Can you expand yourself on the subject ? I did followed 
discussion on the topic, and so this thread is quite hard to 
follow.
April 15, 2013
Re: Is there any plans to make working signals in D?
15.04.2013 7:46, deadalnix пишет:
> On Sunday, 14 April 2013 at 07:06:12 UTC, Denis Shelomovskij wrote:
>> For "working signals" I suppose will be enough fixing of both Issue
>> 9606 [1] and Issue 9603 [2].
>>
>> IMO, for the first issue we need weak references [3].
>> IMO, for the second issue we need to make regular D objects on
>> closures [4] and fix Issue 9602 [5].
>>
>> Any thoughts about my proposal to make signals working in D? Other
>> proposals? Any (approximate) period for [proposal parts] to be
>> implemented?
>>
>> Also, does anybody think currently D has working signals and I'm just
>> slander in the title?
>>
>> P.S.
>> Also there is a proposal for new signals implementation without
>> compiler changes [6].
>>
>>
>> [1] http://d.puremagic.com/issues/show_bug.cgi?id=9606
>> [2] http://d.puremagic.com/issues/show_bug.cgi?id=9603
>> [3] http://d.puremagic.com/issues/show_bug.cgi?id=4151
>> [4] http://d.puremagic.com/issues/show_bug.cgi?id=9601
>> [5] http://d.puremagic.com/issues/show_bug.cgi?id=9602
>> [6] http://d.puremagic.com/issues/show_bug.cgi?id=9347
>
> Can you expand yourself on the subject ? I did followed discussion on
> the topic, and so this thread is quite hard to follow.

My points was:

1. Implement a weak reference (and, better, a weak references array) as 
a general utility [3] and don't implement it in every case we need it 
(this will make `std.signals` fixing [1] trivial, one will just 
supersede incorrect internal weak ref implementation with standard one).

2. Make regular D objects on closures [4] to be able to know when 
delegate's outer scope is destroyed (this will auto-fix both [5] and 
[2], see Comment 2 of [2] for code example)


I think both points are relatively easy to implement and will improve 
things a lot.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
April 15, 2013
Re: Is there any plans to make working signals in D?
14.04.2013 21:07, Robert пишет:
>> Does it mean you disagree with proposed compiler changes and with the
>> idea we have to create weak reference functionality instead of
>> recreating it every time it is needed (beside of theoretical danger such
>> approach already showed it as a bad thing with `std.stdio.File` as I wrote)?
>>
>
>
> A weak reference could actually be implemented in the library relatively
> easy. ( I basically did it for std.signals2 ) But for std.signals a weak
> ref is not really enough, because ideally the slot gets removed if the
> target gets destroyed, not only set to null. Updating a collection on
> destruction of an object is not that easy as you pointed out (thank you
> for that), but I don't see how weak references would help there.

Array of weak references is what is needed.

>
> But you just made me think: If it is ok that a signal does not release
> the memory for the slot immediately when the object gets destroyed but
> only on the next call to emit(), then the implementation would be much
> simpler ...

Yes, this is how array of weak references will work because this is how 
weak references work. And this shows one mustn't implement general 
facilities in every case they are needed as he will do mistakes and will 
complicate thinks for himself.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home