wkhere / bcl / 9036087583

91%

push

github

ParseFile: eliminate data race, always wait for parse to end

Previously, ParseFile after encountering read error could return without
waiting for parse goroutine - in effect, if running ParseFile once was a
sole thing done by the program, the process could end with that goro
killed in the process. No harm done for the API consumer, but kind of
hacky.

There was also data race - after reading read error from the channel,
prog return value could be suddenly overwritten by the just-ended parse
goro, as there was no further synchronization. This was potentially
harmful, with uncertainty if prog returned will be nil or the one from
parse.  Now I am always waiting for parse to finish - it will finish
soon in the presence of errors - and always returning its prog, which is
atm non-nil always (partly created if there were errors). This makes
sense, as it could be disassembled at least (actually worth coding it).

Another outcome of the synchronization done now is: if there are both
read error and parse error (hard to have former without the latter btw),
read error will always be the one returned from the API (not only when
parse error was *caused* by the lack of input coming from errored read,
but *also when parse error happened before read error*,
in the successfully retrieved text part. Well, even if the parse error
was first on the time axis (reads and parsing are done concurrently), it
doesn't matter - it is more logical to give the user the read error, as
it conteptually happens first in the pipeline. The fact that it may
occur later when concurrency is involved seems to be an implementation
detail. Before if was depending on the inverleaving of the goroutines
sending to errc channel - so really nondeterministic.

Btw, data race was checked with go test -race .

6 of 6 new or added lines in 1 file covered. (100.0%)

1523 of 1694 relevant lines covered (89.91%)

0.98 hits per line