CultureInfo.CurrentCulture not being preserved across Threads on Linux

[ryanbrandenburg]

MVC seems to have encountered a problem whereby the CurrentUICulture is not preserved across threads on Linux (windows works fine). If you run this project on windows, go to /Home/Index and request "fr" as your language all the fields should display french data. However, if you run it on Linux AND the Controller and View execute on different threads then you will get English as the CurrentUICulture of the View because it's not preserved across the thread switch and English is the default.

Here's a screenshot of what it looks like when this happens:

Basically we set the CurrentUICulture of the thread based on your request (query-string, header or cookie), the Controller receives that Culture without trouble, we do something async, then create our View. The view doesn't have the same culture as the Controller by the time it executes.

Also of note is that if you keep trying this you will stop getting the English results because it becomes more and more likely that the View thread will be "pre-populated" with french from when it previously hosted the Controller.

CC @rynowak and @javiercn to make sure I explained it fully and understandably.

[Eilon]

Marking as blocking-partner because this is a critical ASP.NET scenario.

@DamianEdwards FYI

[janvorli]

@stephentoub - this is a corefx rather than coreclr issue, right?

[stephentoub]

@janvorli, if there's a bug here, it would actually be due to code in coreclr/mscorlib as that's where the implementation for all the relevant types live, e.g. CultureInfo, ExecutionContext, etc.

@ryanbrandenburg, how is work being passed across threads, i.e. what APIs are being used? Are you queuing work with Tasks? Using just async/await? Is there a custom SynchronizationContext involved? Etc. It'd help if you could provide a small console-based repro using just the relevant APIs, outside of all of the MVC machinery.

cc: @tarekgh

[janvorli]

@stephentoub Ah, right, I got somehow confused.

[rynowak]

@stephentoub this is all async/await without a custome context.

Simplified, the execution graph looks like:

Loc Middleware (sets Culture) -> MVC Invoker -> Controller (user code) -> Task.Delay
                                             -> View (user code)

All the arrows represent awaits and the second piece of user code (View) is observing an unexpected value of the culture. I'll talk to @ryanbrandenburg about putting together an isolated (non-MVC) repro when he arrives.

[tarekgh]

this could be because we have different globalization code used in Linux than Windows. but having non MVC sample will help in the repro. I'll try to take a look later today.

[ryanbrandenburg]

Here is a repro app https://github.com/ryanbrandenburg/ThreadedCultureRepro. As with the MVC repro, it works as you would expect on windows but gives the wrong culture when the second half happens on a different thread in linux.

[tarekgh]

Thanks @ryanbrandenburg I'll try that. I am seeing the Linux code is not having the async logic with the current cultures so I am working to fix that. will update you when I have more news.

[tarekgh]

CC @ericeil as FYI

[ryanbrandenburg]

@tarekgh we'll pick get this fix the next time we pick up new CoreCLR packages now that it's merged, correct? If so I'll close this out.

[tarekgh]

@ryanbrandenburg yes it is merged. I am currently adding the test for it. you can close this one if you like.

[ryanbrandenburg]

Thanks!

[DamianEdwards]

I notice this issue is in the RTM milestone. We want this for RC2, do we need to change anything here?