declare work item for concurrent read of stderr as a non-optional

[sohocoke]

To fix a warning from xcode thread sanitizer.

[kareman]

Hi, thanks for pointing out this issue. But even after applying your fix, Xcode (10 GM) still complains about a data race in line 158 (self._stderror = _stderror) when running unit tests with the thread sanitiser enabled. Does your fix remove a warning when using SwiftShell from your own code?

[sohocoke]

Hmmf, just found the warning appears when I exercise a more exhaustive code path that invokes SwiftShell. I had first thought the error was because the thread sanitiser didn't fully grok #wait called on an optional, but it seems optionality was immaterial. So, this PR doesn't really fix the issue.

It would be preferable to replace all the work in RunOutput#init(launch:) -- launching the task and obtaining the output -- with an asynchronous method.

• Stdout / stderror can be asynchronously delivered to a closure after being read, resulting in no potential race conditions to even think of.
• It would be an opportunity to resolve the awkwardness of having a process launch on the back of creating a RunOutput object.
• It would make instantiating RunOutput and the launching of the task safe to perform on the main thread / queue; currently it wouldn't be wise to do so, since anything that blocks or delays the concurrently performed work to process stderr, can end up blocking the main thread and give us a SPOD.

[kareman]

I’m afraid I don’t quite understand what you are suggesting here. I’d love to see a PR of it if you have the time.

[sohocoke]

@kareman Please see PR #69 for an implementation of the previous suggestion.

[kareman]

Is continued in PR #69