Should fileReader / fileWriter be unlocking by default? (or un-defaulted?) about chapel HOT 6 CLOSED

This question asks whether we think we have the wrong default on fileReader / fileWriter as well, and would want to switch it to non-locking, or just remove the default to require the user to think about it.

I agree that in many cases users actually want a non-parallel safe fileReader/fileWriter, and are unaware that this isn't what they're getting; however, I'm somewhat wary of changing the default value in all cases. I'd propose that we make the following changes to make it more likely that users get the locking behavior they want:

1. Remove locking's default value in the file.reader and file.writer methods. Since these methods are more amenable to scenarios where multiple readers/writers are being created around the same file, this forces users to think about whether they need parallel safety in those cases. For example:

var f = open("path/to/file.txt", ioMode.r);

coforall tid in 1..nTasks {
  var taskReader = f.reader(locking=true, ...);
  ... 
}

note: we could also consider simply keeping the default value of true for these methods

2. Switch the default value to false for the openReader and openWriter standalone procs. In my experience, these are used more commonly in cases where a user only wants one reader/writer to a particular file. For example:

proc getIntFrom(file: string): int throws {
  return openReader(filePath).read(int);
}

Additionally, I consider these to be convenience functions, and thus would prefer to have default values for as many arguments as possible.

3. Remove the default value for locking from the fileReader/fileWriter types themselves, implying that parallel safety should be decided on a situation by situation basis.
   • As you mentioned above, I agree that stdin, stdout, or stderr should be parallel safe due to their global nature.

from chapel.

Not sure if such a flag would be reasonable to toggle stdin/stdout/stderr having locking or not.

I'm always hesitant to have program behavior depend on a flag that isn't visible in the source code, so of the options, I like the notion of having a fastStdin or the like instead. That would also permit both fast and safe uses of stdout within a single program, I think. Alternatively, we could have a FastConsole module or the like whose use/import would define stdin/stdout/stderr to be the fast versions within that scope. But I worry a bit about how that would mix with standard uses of the IO module (and it seems like it could lead to confusion and definitely the inability to mix the two notions of the console in a current scope).

I'll fork this off into its own issue if nobody objects (and I don't find we've already got one).

from chapel.

Only tangentially related, but: Would any of you following this issue so far have any appetite for introducing an unlocked version of stdin/stdout/stderr as part of this effort? (the goal being to have low-overhead shootouts that don't have to rely on the open file 0 trick that we currently have). I think the only hard part is the naming (e.g., stdinUnlocked? stdinNoLock? lockFreeStdin? they all seem clunky...?)

from chapel.

@bradcray - I'd expect we'd also want stdin/stdout/stderr that works directly with the OS rather than using line-buffering and working through a FILE*. In the past I've considered maybe having a compilation flag (maybe a config param or something?) to opt out of the current mode which could be described as "stdout etc interoperate with C but are slower". Not sure if such a flag would be reasonable to toggle stdin/stdout/stderr having locking or not.

On approach would be to have something like fastStdin that isn't locking and also disables the C interoperability.

from chapel.

Regarding fastStdout etc, another thing it might do is to do separate buffering per locale in order to be more efficient in distributed environments. It would give up line-based interleaving of the output from different locales.

from chapel.

This was resolved, closing

from chapel.