wkhere / bcl / 9036087583 / 1
91%
master: 91%

DEFAULT BRANCH: master
Ran
Files 18
Run time 1s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 89.906% (+0.02%) from 89.882%
9036087583.1

push

github

wkhere 
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 .

1523 of 1694 relevant lines covered (89.91%)

0.98 hits per line

Source Files on job 9036087583.1