Skip to content

Conversation

@majocha
Copy link
Contributor

@majocha majocha commented Feb 14, 2024

It looks like any call to NodeCode.AwaitAsync (there are many in Transparent Compiler) is at risk of getting wrong threadstatics?

I've seen some randomness of that kind in #16701. Mostly the threadstatics get eventually restored at some point, but the potential for chaos is there.

I also added a modified AsyncMemoize test to show the problem.

@majocha majocha force-pushed the nodecode-awaitasync branch from 38e04e3 to 0cbbd65 Compare February 14, 2024 17:41
@github-actions
Copy link
Contributor

✅ No release notes required

@majocha majocha changed the title The problem with NodeCode is not fully fixed. Yet another NodeCode problem affecting AsyncMemoize Feb 15, 2024
@majocha majocha marked this pull request as ready for review February 15, 2024 11:42
@majocha majocha requested a review from a team as a code owner February 15, 2024 11:42
@0101
Copy link
Contributor

0101 commented Feb 15, 2024

Wait, so are there wrong thread static in the async / task computation that we invoke from node, or do they also get corrupted when we're back in node? If it's the former we could probably say, if you want to use thread statics build phase / logger, you need to use node ?

Also, does switching to AsyncLocal fix this?

@majocha
Copy link
Contributor Author

majocha commented Feb 15, 2024

From my understanding, once we're in normal async, the flow of diagnotics state stops. So every time there is a thread switch in async, we end up with a wrong or null logger. This corrupts other running nodes, as long as there are any any diagnostics updates or, even worse, swapping of global diagnostics logger in such an async task.

I guess this is not very impactful because almost everything we have is wrapped in node.

And yes, AsyncLocal does not have that problem.

@majocha
Copy link
Contributor Author

majocha commented Feb 15, 2024

There are some things that further mask this problem. For example, we have implicit initialization if there happen to be a null logger in DiagnosticsThreadStatics getter.

I tried to remove this initialzation and swap it for explicit initialization at service boundary (any FCS service call sets defaults first). I then observed naked nulls showing up in AsyncMemoize.Get. So it seems the corruption sometimes gets through.

@0101
Copy link
Contributor

0101 commented Feb 15, 2024

Hmm, so basically we shouldn't have anything that is not node-wrapped touch the thread statics. Then it would be ok?

Anyway this seems like another good argument to switch to AsyncLocal.

@majocha
Copy link
Contributor Author

majocha commented Feb 15, 2024

Yes, that's exactly it. At least nothing that has potential to produce diagnostics or modify the global diagnostics logger should be executed.

@majocha
Copy link
Contributor Author

majocha commented Feb 17, 2024

One thing I noticed is ParseFile runs in normal async and can produce diagnostics.

@abonie
Copy link
Member

abonie commented Mar 25, 2024

Hey @majocha , is this PR good to go or are you planning to make some more improvements or tests?

@majocha
Copy link
Contributor Author

majocha commented Mar 25, 2024

This is more an issue than a PR, I will close this to not clutter things.

@majocha majocha closed this Mar 25, 2024
@majocha majocha mentioned this pull request May 6, 2024
2 tasks
@majocha majocha deleted the nodecode-awaitasync branch November 4, 2024 12:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

3 participants