Refactor SynchronizationContext to provide order and execution guarantees

[peppy]

No description provided.

[peppy]

Needs further consideration. Dunno how this is supposed to work.

[peppy]

I've updated the implementation to match expectations of Windows Form / WPF in the table on https://docs.microsoft.com/en-us/archive/msdn-magazine/2011/february/msdn-magazine-parallel-computing-it-s-all-about-the-synchronizationcontext. I think this is closest to what we want.

Note that as a result, the Send method is running through the scheduler queue. If this is seen as dangerous (due to a potential expectation that it is to be run at precisely the start of the update method - I'm not sure how much water this holds) then we can make an isolated scheduler or local queue for the SynchronizationContext implementation.

I'd recommend reviewers do their own reading on the topic, the linked page above is worth a read, potentially twice over.

I'll add tests (covering order of execution and inline execution constraints) once we come to an agreement.

[smoogipoo]

Is there a reason for Send to run through the scheduler queue? I see nothing in that doc which indicates that this is a guarantee of SynchronizationContext.

[peppy]

Relevant sections:

I propose we match WPF/winforms for sanity, and because correct ordering is required for the realm case I'm making work with this change.

[smoogipoo]

I guess we have different readings for what "execute in queue order" means.

It doesn't look like the WPF dispatcher preserves ordering between Post and Send when looking at the source. For example, their Send implementation eventually runs into a "fast path" which runs the callback immediately. Or you could look at the documentation of DispatcherPriority.Send which they're passing in through this particular pathway in the Send method, which states: "Operations at this priority are processed before other asynchronous operations".

[peppy]

Those both seem dependent on a priority enum though. Is the Send priority a default in the case of syncContext.Send?

Regardless, I wouldn't want to get that complex. As per the MS documentation, implementation is up to the implementation, and enforcing order isn't going to break anything.

[smoogipoo]

Put another way, I definitely feel uneasy running every single scheduled delegate immediately.

[peppy]

I don't necessarily disagree. Would you be okay if it was isolated from the game thread scheduler? That would remove any uneasiness from my end.

[smoogipoo]

Yes, that would be fine

[smoogipoo]

Those both seem dependent on a priority enum though. Is the Send priority a default in the case of syncContext.Send?

To answer this question, it seems like the default priority is Normal: https://source.dot.net/#WindowsBase/System/Windows/Threading/Dispatcher.cs,1784. The Send priority is a very special case which allows only those particular callbacks to be executed immediately (but not the rest of the queue).

[peppy]

Tests and logic should be good to go.

[bdach]

I don't have a huge amount of knowledge about sync contexts but this pretty much matches what I'd expect to see out of one.

One thing I'm not entirely clear on is when the game will actually use Send(), if at all. But maybe that will become clear when I look at that part.