I've been playing around with concurrency lately, and I brought up a limitation (which I feel is very strong): Basically, each MessageBox are thread-global objects.

Because of this, it is not possible (or at least, very difficult) to create *objects* that own other threads and communicate with said threads, all from the same master thread.

It turns out the limitation is mostly artificial. I added a couple of lines to concurrency, and I was able to *very* easily deploy code such as:

//--------
import std.stdio;
import std.concurrency;
import core.thread;
import core.time;

void job(Tid ownerTid, string s, Duration duration)
{
    Thread.sleep(duration);
    ownerTid.send("Job " ~ s ~ " has finished.");
}

struct Manager
{
    string name;
    Tid myTid;
    this(string name, Duration duration)
    {
        this.name = name;
        myTid = generateMessageBox(); //New in concurrency
        spawn(&job, myTid, name, duration);
    }
    void get()
    {
        myTid.receive( //Specific member function to Tid
            (string s){writefln("Manager %s say: %s", name, s);}
        );
    }
}

void main()
{
    auto a = Manager("a", seconds(5));
    auto b = Manager("b", seconds(1));
    auto c = Manager("c", seconds(3));
    Thread.sleep(seconds(10));
    a.get();
    b.get();
    c.get();
}
//--------
Manager a say: Job a has finished.
Manager b say: Job b has finished.
Manager c say: Job c has finished.
//--------

As you can see, my main has created 3 Managers, all of which spawned their own thread. Each manager can easily speak to its job, via its own private MessageBox, with no risk of collateral noise.

Most importantly, deploying this code was *bafflinggly* easy and straight forward. Furthermore, it reduces to *nothing* end user message management.

In particular, imagine if "Manager" was instead:

struct AssyncFileCopier
{
    this(string origin, string target);
    bool areYouDoneYet();
}

Again, implementation would be VERY straight forward.

Without such local MessageBoxes, I don't know how you'd tackle the problem.

One thing is for sure, I don't think it would be very pretty...

--------

The question is: I'd like to put a bit more work into this, flesh it out, maybe write a DIP, and submit to phobos for inclusion.

Does anybody have any preliminary feedback, objections, remarks?

Reply via email to