PTAL, hopefully this will help @DanTup.

Fix seems good to me, thanks! :)

Before:

After:

@aam Btw, I presume this issue was specific to how evaluations are routed back to Flutter and didn't affect non-Flutter apps? I noticed the fix was in flutter_tools; but I can't repro any issues when running directly on the desktop VM.

@DanTup wrote

@aam Btw, I presume this issue was specific to how evaluations are routed back to Flutter and didn't affect non-Flutter apps?

That's right. For standalone Dart VM(non-Flutter apps) there is different(conceptually similar) wrapper. We might have to have similar fix applied to that wrapper(kernel service) too.

Hello, I realize this PR is from quite a while ago, but could someone explain why this was necessary (@DanTup)? This PR introduced a code comment that says that we serialize compilation requests, but it doesn't explain why we need to. Looking at #18595, I'm guessing that we need recompilation requests to be processed in-order because one compilation request can depend on a previous one. Is that a correct reading?

This has come up because of #151255, which is blocking fixing the top crasher of the flutter tool. I'm considering refactoring the tool's ResidentCompiler APIs to return a pair of futures (one for compilation starting and one for the actual result of the compilation). However, before making these APIs more complicated, I want to make sure that sequencing of compilation requests is actually necessary.

Looking at the original issue I'm not certain, but here's a guess (possible @aam can correct me). I think this might be because the way the expression compilation is done is by just sending strings over a stream bare and a response is received:

>>> expression
<<< response
>>> expression
<<< response

Since these aren't wrapped in anything to indicate which request a response relates to, having multiple requests trying to send requests at the same time might mess things up:

>>> expression1
>>> expression2
<<< response // which expression is this the response to?

My guess is that serialising these into a queue like this was an easy way to fix the issue. It would probably be better if these requests were more structured though (I think we have another open issue somewhere that newlines in an expression will break?). We use something like JSON-RPC for many other tools (like the Flutter daemon), maybe something similar would work here?

(I'm not sure how this is causing your issue though, but I'm not all that familiar with either parts of this code)

Thanks for the response!

(I'm not sure how this is causing your issue though, but I'm not all that familiar with either parts of this code)

Sorry for not elaborating here. I think you are already familiar with dart-lang/sdk#54911 (writing to a process risks an uncatchable error that will often have no meaningful stacktrace), which is affecting the flutter tool greatly. In the flutter tool, we've implemented a workaround to this using runZonedGuarded. However, this implementation is based on IOSink::flush, and you can only have one outgoing flush at any given time. Said another way, any call to this workaround should be awaited before making another call so that we don't end up with two concurrent flush calls. ResidentCompiler is one place in the tool where we make several writes to a process. However, adding awaits there results in a performance regression (see aforementioned #151255). Thinking about this again, I don't think this issue blocks the tool making progress here. I could instead only call the workaround for the last write; it would just be a bit confusing to readers. Sorry if this was hard to follow—in summary, I don't think ResidentCompiler being written to process requests sequentially is blocking anything. It's just the reason is not well documented, and I was hoping I could better understand it and possibly document it myself.

Ah gotcha, thanks for the explanation! (and I agree it would be good to document the reasons for this if they're not clear in the code - though it's probably worth some confirmation from @aam or @a-siva if my assumption above is correct before documenting it as such 😄)