stdin/stdout/stderr store the dummy locale rather than locale 0

[bradcray]

Summary of Problem

Background: Our file/fileReader/fileWriter types store a locale field named _home that stores the locale on which they originated. As I understand it, this is becaue they are record types (rather than classes or records wrapping classes), such that they may be copied around yet always need to know what locale they are associated with to ensure that any interaction with the C-level FILE* types and the like are done from the right process.

Chapel has a 'dummy locale' value which is set up at the beginning of time before the Locales array is set up (or ready to be) such that any early references to here will refer to the dummy locale. The challenge in setting up the Locales array earlier is that the Locales array is defined in terms of DefaultRectangular domains and ranges; those types are dependent on IO for some of their capabilities; and IO is where stdin/stderr/stdout are defined (which store a _home field as noted above).

The problem: The console-oriented stdin/stdout/stderr channels store the dummy locale as their _home field, such that a check like this:

    if data.locale != this._home {

will return false. As a workaround, the check can be converted to:

    if data.locale.id != this._home.id {

since the dummy locale has an ID of 0, like locale 0 (for better or worse... maybe the dummy locale should be storing -1 as its ID to make it more obviously dummy? But then if we did that, we couldn't apply this workaround.

I've spent chunks of time over the past week trying to address this, unsuccessfully, trying approaches like:

• poking Locales[0] into the _home field after the world is set up — but this can't be done because stdin/stdout/stderr are const, so can't be modified after they're established
• setting up locale 0 before the Locales array is ready to be set up and then poking it into the Locales array as we're setting it up. This worked for the 'flat' locale model but not for the 'gpu' locale model due its use of a DR domain/array to store its sublocales, causing the same circularity as described above
• trying to disentangle the setup of internal locales, teasing key components into modules of their own to make the interdependencies a bit less like spaghetti snarls... but timed out before completing this effort

Some other ideas I've considered but not attempted are:

• getting rid of the _home field and making these types more of a proper record-wrapped class, where the class embeds the locale and file pointer on that locale in order to remove the need to capture the locale—to me, this sort of singleton "I must live here and not be copied" pattern is exactly where classes are designed to be used
  • if this was successful, I'd also try putting a halt() into any early queries of here that would return the dummy locale to see whether there were other instances of it
• making stdin/stderr/stdout be paren-less procedures that return variable versions of the channels such that the new locale field could be poked in after the fact

Steps to Reproduce

Associated Future Test(s):
test/library/standard/IO/consoleOnLocale0.chpl #23693

Configuration Information

• Output of chpl --version: chpl version 1.32.0

[bradcray]

#23824 was my attempt at replacing the dummy locale with locale 0 from the get-go, which was very nice in terms of code cleanup and removing dummy stuff, but didn't work for the GPU locale model as described above (and on the PR itself).