On Thu Sep 12 16:25:05 2024 +0000, Gabriel Ivăncescu wrote:
Yeah, what I mean is that we're supposed to block tasks (the point of the MR) if we're in a nested message loop. This works fine without sync XHRs. For sync XHRs, Gecko uses a message loop and expects the tasks to be processed (probably the ones you said in `nsio.c`). Now what if a nested message loop (that should block all tasks!) calls sync XHR send() at some point? It has to process the tasks, else Gecko hangs. So, I took the "safe" approach and process all tasks in such case—i.e. behavior as before this MR (I set `tasks_locked` to 0 during sync XHR send, then back to its previous value; nested message loops within sync XHR send will still not get processed and that's fine). Granted, I doubt it will happen in practice, so it's probably good enough, but if it does we can probably revisit it. We should probably keep it simple for now. BTW note that it's more than just the sync XHR io tasks themselves. As I said, even tasks related to prior async XHRs in the xhr.js tests had to be processed for some reason (which have nothing to do with the sync XHR), else it hanged. That's why I gave up trying to "only process tasks related to sync XHR" (IO or otherwise) which was my idea originally that failed, and went with something simpler for such a niche case.
For sync XHRs it seems pretty complicated due to gecko internals. For example, my idea was to process tasks at a given "depth level" only, or those pushed on such depth level (which gets changed on a sync XHR, and otherwise is zero). This means only sync XHR tasks get processed in the sync XHR. In theory it sounds fine and correct, but the sync XHR tests fail.
That's because those tests first create two async XHRs and then a sync XHR. It appears that gecko will simply hang if we don't process the async XHR tasks in the sync XHR message loop…
So maybe we should just execute all tasks at given depth level or before it—but not after. This won't be completely correct for sync XHRs but I think this is a fringe case that doesn't happen in practice? The async operation would be correct wrt. task nesting, and also sync XHRs keep their current behavior when no nested message loops happen, which is important as well.
(currently battling test failures due to an issue I don't understand but yeah)