Re-add Object.notifyRegister and notifyUnRegister

The phobos 'register' functions have some issues. Instead of replicating that, Tango has a somewhat different (and safer) approach to S&S.

The current S&S design is closer to the Boost implementation than the Qt implementation in that connected objects must be explicitly disconnected. For explanation, assume that notifyRegister is being used and that a connected object is being collected by the GC. The connected object is finalized and this triggers the callback intended to disconnect it. The first step in a multithreaded S&S mechanism will be to acquire a mutex protecting something so this removal can take place. Let's assume in this instance there is a mutex protecting the list of connected objects. Let's further assume that a signal is currently firing and this mutex is locked. Since all threads but the GC thread are currently suspended, the GC thread will try to acquire this mutex, see it is locked, and wait for it to be released, which, since the thread holding the lock is suspended, will be forever.

An alternate (very expensive) approach would be to protect each individual object in the list with its own mutex. With this, the chances for a deadlock occurring are smaller, but not zero, because the signalling object could still be signalling the thread to be deleted at the exact same instant it is collected. Again, deadlock.

Now just for kicks let's say the design uses a lock-free method to signal instead of mutexes. And like the above approach, each connected object has a proxy object:

struct Proxy
{
    void disconnect()
    {
        dg = null;
    }

    void signal()
    {
        if( dg )
            dg();
    }

    void delegate() dg;
}

Also, like the above example, let's assume that a signal is firing for the connected object the exact instant it is collected, so that the following sequence of events occurs:

* The signalling objects loads the value of dg into a register and compares it to null. It is not null so the object gets ready to call dg. * The GC starts a collection and suspends all threads, including the signalling thread. * The GC finalized the connected object being called, setting dg to null. * The GC completes and resumes all threads. * The signalling object calls dg based on the value it had stored in a register (which is not null) and the application segfaults.

In short, I haven't been able to come up with any design for automatic removal using weak pointers and a GC that will not either deadlock or crash a multithreaded program. Thus, the current design requires the user to explicitly disconnect objects and uses real pointers (instead of weak pointers) in hopes that this will prevent Bad Things from happening.

Also, in light of the above problems with weak pointers, GC, and S&S, I don't see a valid use case for notifyRegister to exist. Another reason being that adding it complicates the monitor object, which in turn makes overriding object monitors (which is done by integrated mutexes) much more error-prone. So unless someone can providing a compelling use case for notifyRegister that doesn't exhibit problems in a multithreaded application, I want avoid having it as a feature in the Tango runtime. I apologize for the inconvenience this causes, but I hope that you understand it is for valid reasons.

Ah okay. I just figured that you were going to reimplement the methods by reading that forum post.

I'll convert to tango's s&s model.

I've considered it, but so far I haven't come up with a design that works, given the issues mentioned above. And I really don't want to offer something that is going to break in weird ways when application complexity increases--given the choice, I'd rather have people change their programming model a tad than have their app unexpectedly crash or deadlock. So an upgrade of S&S is on hold pending a suggestion for how to avoid these problems.