Possible race condition between Fini and PollEvent

[squizzling]

Both cScreen and tScreen will eventually set their stopQ channels to nil in response to Fini. This update of the struct field is protected by a mutex, however the read of the field in PollEvent is not, which triggers a data race.

While the documentation for PollEvent does indicate it should be called from the main loop, it isn't clear about who is allowed to call Fini. However from the locks, it appears that Fini is intended to be callable from anywhere, thus making the underlying data shared rather than exclusive to the main loop.

As such the data access should be protected in PollEvent as well, even if PollEvent is only allowed to be called from a specific routine. Alternatively, Fini should be documented to only be callable from the main goroutine as well (this is an API break, however)

[gdamore]

Fair point. What I'll do is move the clearing of that to after waiting for the waitgroup.

[gdamore]

PollEvent does not read from the stopQ in the tscreen implementation. It would be an error to call PollEvent when the application is not started. I will change Fini not to clear it, but I do need to set it during start().

[gdamore]

(For anyone watching ... its pretty unlikely that you'll ever actually hit this as a real world bug.)

[squizzling]

PollEvent does not read from the stopQ in the tscreen implementation.

My bad, I confused myself!

Thanks for the quick response.