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 <[email protected]> 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 > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
