[DGD] More on asynchronous thread starts

[Shentino]

The idea I was talking about probably means you wouldn't have to.

If you provide an MP interface for exec-round injection, it can look
the same in both DGD and DGD/MP.

Say I want something done LPC-side in response to some custom event.

I just call the exported "inject_exec_round(object obj, function f,
mixed args)" (or whatever), and then check the return value.  If I get
"OK", then that means the exec round completed, and then committed
properly.  My package's job is done, and any LPC state changes
resulting from the injection are committed much as they would be if
DGD's own native code started the event.

If, however, I get "RESCHEDULED", meaning that there was a committment
failure, my package just tries again later, perhaps requesting a
higher priority of some sort to avoid endless rescheduling.  Or,
perhaps it could try again automatically.

Now, if this interface were layered on top of plain old DGD, the
interface would remain the same.  What woudl actually happen on the
"other side" would be very different indeed.

For instance, since it's single threaded, there's no such thing as a
reschedule, and any hooks required to deal with MP specific stuff
would simply collapse into a no-op.  My extension, by interfacing with
the MP interface, woudl also work properly with a "mock MP" interface
that stubs out the stuff that isn't required for plain DGD.

If there are in fact fundamental differences, then a simple macro of
"#ifdef MP" could take care of them.  If I were writing an extension,
I wouldn't mind bearing the same burdens that the server does when it
responds to its own external happenings.

My main rant is that it isn't fair for DGD or DGD/MP's own native code
to have a monopoly on launching exec rounds in response to
asynchronous events.