Review of std.signal

[Kagamin]

On Friday, 17 January 2014 at 13:31:10 UTC, Robert wrote:
> On Friday, 17 January 2014 at 08:46:33 UTC, Kagamin wrote:
>> 1. there're two typical usage patterns of signals: you mostly 
>> have 0 or 1 slots attached, so it would be nice if having one 
>> slot wouldn't require allocation. SlotsArray should be 
>> probably a tagged union of SlotImpl and SlotImpl[]. Is it 
>> worth an effort?
>
> Well it depends. One of my goals was to minimize memory usage 
> of an empty signal, using a tagged union would increase the 
> space used by an empty signal. (A slot consists of 3 pointers + 
> memory for the tag, the array consists of a pointer and a 
> length)

We can infer the tag from one of the pointers and use two other 
for the array. I suppose, _funcPtr can't be null in a 
meaningfully filled slot, so if it's not null, that's a slot, 
otherwise _dataPtr and _obj are array's ptr and length 
respectively. So it's only 1.5 bigger.

>> 2. why InvisibleAddress is so big? Isn't it enough to just 
>> negate it?
>
> For 64 bit yes, but not for 32 bit. InvisibleAddress handles 
> both.

False pointers. I'm afraid, 32-bit has them any way.

>> 3. I think, it's important to document, that a weak connection 
>> can be destroyed before it becomes logically unneeded. It's an 
>> important and non-trivial caveat.
>
> How is this supposed to happen?

If you attach an object to a slot and then lose the last 
reference to it.