sslot 0.3 release

[Sean Kelly]

Lutger wrote:
> Lutger wrote:
>> Dejan Lekic wrote:
>>> Lutger, my suggestion is to do what QT does - 
>>> http://doc.trolltech.com/4.2/threads.html#signals-and-slots-across-threads 
>>>
>>>
>>> Kind regards
>>>
>>> PS. I would like to see this in Phobos' signal/slot implementation.
>>
>> Thank you for the link. It is still not clear to me what is necessary, 
>> the QT s/s mechanism is tightly integrated to the whole framework so 
>> not seems to be applicable.
>>
>> What it comes down to looks like a lot of mutexes to me though. I am 
>> not so familiar with multi-threaded programming, perhaps you can help 
>> me with these questions:
>>
>> Would it be preferable to have a thread safety as an option, and if so 
>> in what way? Versioning or seperate classes?
>>
>> Do reads from (non-volatile) data need to be synchronized?
> 
> I found the answers to my own questions, but upon reflection there seems 
> to be a lot of potential for deadlocks. It will probably take a while 
> for me to figure out the details, I don't want to infest sslot with 
> subtle bugs.

There are a few different approaches available, depending on the 
guarantees want to provide.  I think Andrei actually wrote an article on 
this, but I'll be darned if I can find it right now.  One approach would 
be something like this:

void attach( Slot s )
{
     synchronized
     {
         if( !signaling )
         {
             slots ~= s;
             return;
         }
         queue ~= AddRemove( s, true );
     }
}

void detach( Slot s )
{
     synchronized
     {
         if( !signaling )
         {
             slots.remove( s );
             return;
         }
         queue ~= AddRemove( s, false );
     }
}

void signal()
{
     synchronized
     {
         ++signaling;
     }
     foreach( s; slots )
     {
         s();
     }
     synchronized
     {
         if( signaling == 1 )
         {
             foreach( m; queue )
             {
                 if( m.isAdd )
                     slots ~= s;
                 else
                     slots.remove( s );
             }
         }
         --signaling;
     }
}

struct AddRemove
{
     Slot slot;
     bool isAdd;
}

The tradeoff here is twofold: first, the signal mechanism must acquire 
two locks to send a signal, and second, the processing of add/remove 
requests is asynchronous when a signal is being sent.  Still, it only 
uses one lock and behavior is fairly predictable.


Sean