Create a Chapeltastic way of getting unlocked `stdin`, `stdout`, `stderr`

[bradcray]

Today, Chapel's stdin, stdout, stderr fileReaders/Writers use locking by default in order to support multiple tasks printing at the same time (as in our hello world examples) in a way that the output will still come out coherent. However, in studying shootouts (and other codes), we find that creating a non-locking version of these channels can result in significant performance improvements, so is sometimes desirable for advanced programmers or performance-sensitive kernels.

Today, the two main ways to create such an unlocking version are:

var consoleOut = stdout.getFile().writer(locking=false);
var consoleOut = (new file(1)).writer(locking=false);

(but note that there can be a big performance difference between these as observed in #24729 ).

both of which are somewhat verbose and roundabout. This issue asks how we should support such channels in a more Chapeltastic way, such as:

• support a built-in symbol for an unlocked version of each channel, like stdinNoLock, unlockedStdin, stdinNL nonlockingStdin or the like (I'm not crazy about any of these, where the naming challenge is probably the main reason we don't already have these today)
• support a way of getting a locking or non-locking clone of an existing channel, like stdin.nonLocking() (idea proposed by @benharsh)

[mppf]

Is this a duplicate of #23082 ?

support a way of getting a locking or non-locking clone of an existing channel, like stdin.nonLocking() (idea proposed by @benharsh)

AFAIK, this is already possible with init= — see PR #16032.

Something like fastStdout could also avoid the double-buffering and line-buffering that caused the performance difference in #24729.

[bradcray]

Whoops, yes, thank you! How quickly I forget (and how bad I am at searching the right keywords).

Of the two, I think I like this one better. I'll check whether there's any content from the other that should be copied over here before closing it. [edit: seemed like the main thing of value were @mppf's comments on it, which I think his comments above subsume].