Diff Detail
- Repository
- rGHC Glasgow Haskell Compiler
- Lint
Lint OK - Unit
No Unit Test Coverage - Build Status
libraries/base/cbits/inputReady.c | ||
---|---|---|
45 | GHC has its own mechanisms for this sort of thing which integrate into the RTS's error handling framework. See RtsMessages.c, in particular replace abort with barf. |
libraries/base/cbits/inputReady.c | ||
---|---|---|
44 | The docstring of this procedure says
so either the docstring is wrong now, or this code is? |
libraries/base/cbits/inputReady.c | ||
---|---|---|
44 | Good point, I should check if any callers do that. poll() supports -1 == infinite out of the box; I just looked up what happens on Windows, and as usual the results are somewat disturbing: The docs for WaitForSingleObject https://msdn.microsoft.com/en-us/library/windows/desktop/ms687032(v=vs.85).aspx say:
Now, what is INFINITE given that it's a DWORD (32-bit unsigned integer)? It's 0xFFFFFFFF! Or -1. So it would work, and probably did before. But that seems a pretty dangerous value for INFINITE, as that is just 49 days! In other words, I think it was a bug before: If you waited for 49 days and a bit, it would actualy wait forever. Also, I think that it means even the current GHC code is wrong, as there are multiple checks for like if (msecs > 0) { /* wait more */ } else { return -1 }, and those should be waiting more also for the msecs == -1 case. |
Abandoning this in favour of https://phabricator.haskell.org/D4011, which fixes the found issues.