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.

Note that barf doesn't take an fd as its first argument.

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:

If dwMilliseconds is INFINITE, the function will return only when the object is signaled.

Now, what is INFINITE given that it's a DWORD (32-bit unsigned integer)?

This books says it https://books.google.de/books?id=r5tCAwAAQBAJ&pg=PT517&lpg=PT517&dq=INFINITE+dword&source=bl&ots=PSZD9dtkM0&sig=XmJQFp8fSZyg4NW4pQi4Z3rZ8bk&hl=en&sa=X&redir_esc=y#v=onepage&q=INFINITE%20dword&f=false:

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.