3 ms·
It does (or will do, once the checks in the UI code are fixed) exactly what you want it to do. All computation will be done on the UI OS thread. All blocking op
by pron 6y ago
It does (or will do, once the checks in the UI code are fixed) exactly what you want it to do. All computation will be done on the UI OS thread. All blocking operations will release it to do other things so it remains responsive. If you want to compute something outside it -- just spawn another thread that's not mapped to it.
- jayd16 6y agoI feel like I must not be communicating the issue properly. Sometimes, like with with several GL calls or layout operations, you want the UI to be blocked because that is the synchronization model openGL requires. Single thread ordering is not enough. We need specific exclusive scheduling of critical sections and I don't see how this system can understand that without just as much or more work as async/await styles. Perhaps we will get some new way to render UI out of this. I'm excited to see what the UI team comes up with once it all works. However, my pessimistic assumption is that we will simply stick with native non-premptive threading.
- pron 6y ago> I don't see how this system can understand that without just as much or more work as async/await styles I didn't say it was less work; probably just as much. The benefits over async/await are elsewhere: in the tooling support and in the lack of split APIs/programming models.