Problem with select(2) in single threaded runtime.

[Merijn Verstraaten]

Worse, it appears the maximum size of time_t is unrelated to the maximum value accepted by select(2). After diving into my system's header files time_t appears to be 'long', but a timeout of INT_MAX seconds already triggers "EINVAL".

At this point, the only option I see is to verify the max timeout for every platform, by reading the source and/or trying all possible timeouts until the max is found and hard coding these max values using CPP.

If anyone has a better solution, you're more than welcome to enlighten me!

Cheers,
Merijn

> On 3 Nov 2014, at 21:36, Merijn Verstraaten <merijn at inconsistent.nl> wrote:
> 
> While adding a test case for https://phabricator.haskell.org/D407 I noticed that while my initial patch fixed the crash for the threaded runtime, the single threaded runtime was still affected. I dove into the RTS and have hit a snag.
> 
> In awaitEvent (rts/posix/Select.c) select(2) is called with the timeout computed from the Haskell call. On my current (OSX) machine my test case overflows "struct timeval", causing select to return EINVAL and crash the runtime. Unfortunately, there appears to be no portable to find the maximum size of time_t/suseconds_t (the types of the struct timeval fields), and therefore no portable way to avoid this overflow.
> 
> The most practical thing I can think of is to add a configure case that checks sizeof(time_t) and sizeof(suseconds_t) and guesses they're just unsigned values of the relevant type, but I'm open to better suggestions. Alternatively, the solution is to hardcode the max value for every platform, in which case I avoid you all to tell me the maximum value on your specific platform :p
> 
> Cheers,
> Merijn
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs