1. 11 Dec, 2017 1 commit
  2. 24 Nov, 2017 1 commit
    • Niklas Hambüchen's avatar
      base: fdReady(): Fix timeouts > ~49 days overflowing. Fixes #14262. · f209e667
      Niklas Hambüchen authored
      On 64-bit UNIX and Windows, Haskell `Int` has 64 bits
      but C `int msecs` has 32 bits, resulting in an overflow.
      This commit fixes it by switching fdReady() to take int64_t,
      into which a Haskell `Int` will always fit.
      (Note we could not switch to `long long` because that is
      32 bit on 64-bit Windows machines.)
      Further, to be able to actually wait longer than ~49 days,
      we put loops around the waiting syscalls (they all accept only
      32-bit integers).
      Note the timer signal would typically interrupt the syscalls
      before the ~49 days are over, but you can run Haskell programs
      without the timer signal, an we want it to be correct in all
      Reviewers: bgamari, austin, hvr, NicolasT, Phyx
      Reviewed By: bgamari, Phyx
      Subscribers: syd, Phyx, rwbarton, thomie
      GHC Trac Issues: #14262
      Differential Revision: https://phabricator.haskell.org/D4011
  3. 27 Sep, 2017 2 commits
  4. 26 Sep, 2017 1 commit
  5. 19 Sep, 2017 6 commits
    • Niklas Hambüchen's avatar
      base: Add more detail to FD_SETSIZE related error message · 022455ff
      Niklas Hambüchen authored
      Reviewers: bgamari, austin, hvr
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3960
    • Niklas Hambüchen's avatar
      base: Make it less likely for fdReady() to fail on Windows sockets. · ba4dcc7c
      Niklas Hambüchen authored
      See the added comment for details.
      It's "less likely" because it can still fail if the socket happens to
      have an FD larger than 1023, which can happen if many files are opened.
      Until now, basic socket programs that use `hWaitForInput` were broken on
      That is because on Windows `FD_SETSIZE` defaults to 64, but pretty much
      all GHC programs seem to have > 64 FDs open, so you can't actually
      create a socket on which you can `select()`.
      It errors with `fdReady: fd is too big` even with an example as simple
      as the following (in this case, on my machine the `fd` is `284`):
        {-# LANGUAGE OverloadedStrings #-}
        import Control.Monad (forever)
        import Network.Socket
        import System.IO
        -- Simple echo server: Reads up to 10 chars from network, echoes them back.
        -- Uses the Handle API so that `hWaitForInput` can be used.
        main :: IO ()
        main = do
          sock <- socket AF_INET Stream 0
          setSocketOption sock ReuseAddr 1
          bind sock (SockAddrInet 1234 0x0100007f)
            -- 0x0100007f == localhost
          listen sock 2
          forever $ do
            (connSock, _connAddr) <- accept sock
            putStrLn "Got connection"
            h <- socketToHandle connSock ReadWriteMode
            hSetBuffering h NoBuffering
            ready <- hWaitForInput h (5 * 1000) -- 5 seconds
            putStrLn $ "Ready: " ++ show ready
            line <- hGetLine h
            putStrLn "Got line"
            hPutStrLn h ("Got: " ++ line)
            hClose h
      I'm not sure how this was not discovered earlier; for #13525 (where
      `fdReady()` breaking completely was also discovered late) at least it
      failed only when the timeout was non-zero, which is not used in ghc
      beyond in `hWaitForInput`, but in this Windows socket case it breaks
      even on the 0-timeout.
      Maybe there is not actually anybody who uses sockets as handles on
      The workaround for now is to increase `FD_SETSIZE` on Windows;
      increasing it is possible on Windows and BSD, see
      A real fix would be to move to IO Completion Ports on Windows, and thus
      get rid of the last uses of `select()` (the other platforms already use
      `poll()` but Windows doesn't have that).
      Reviewers: bgamari, austin, hvr, erikd, simonmar
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3959
    • Niklas Hambüchen's avatar
      base: Fix fdReady() returning immediately for pipes on Windows. · 66240c9b
      Niklas Hambüchen authored
      See https://ghc.haskell.org/trac/ghc/ticket/13497#comment:17
      Until now, the program
        import System.IO
        main = hWaitForInput stdin (5 * 1000)
      didn't wait 5 seconds for input on Winodws, it terminated immediately.
      This was because the `PeekNamedPipe()` function introduced in commit
      94fee9e7 really only peeks, it doesn't block.  So if there's no data,
      `fdReady(fd, msec)` would return immediately even when the given `msec`
      timeout is not zero.
      This commit fixes it by looping around `PeekNamedPipe()` with a `sleep(1
      Apparently there's no better way to do this on Windows without switching
      to IOCP.
      In any case, this change should be strictly better than what was there
      Reviewers: bgamari, austin, hvr
      Reviewed By: bgamari
      Subscribers: Phyx, rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3956
    • Niklas Hambüchen's avatar
      base: Fix fdReady() potentially running forever for Windows Char devices. · 826c3b11
      Niklas Hambüchen authored
      Reviewers: bgamari, austin, hvr
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3955
    • Niklas Hambüchen's avatar
      base: Fix fdReady() potentially running forever on Windows. · c2a1fa7a
      Niklas Hambüchen authored
      This fixes #13497 for Windows -- at least for the `if (isSock)` part; I
      haven't investigated the case where it's not a socket yet.
      Solved by copying the new current-time based waiting logic from the
      non-Windows implementation above.
      Reviewers: bgamari, austin, hvr
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3954
    • Niklas Hambüchen's avatar
      base: fdReady(): Improve accuracy and simplify code. · 28a115e5
      Niklas Hambüchen authored
      This is done by reusing the existing cross-platform
      `getProcessElapsedTime()` function, which already provides nanosecond
      monotonic clocks, and fallback for platforms that don't have those.
      To do this, `getProcessElapsedTime()` had to be moved from a private RTS
      symbol into the public interface.
      Accuracy is improved in 2 ways:
      * Use of the monotonic clock where available
      * Measuring the total time spent waiting instead of a sum
        of intervals (between which there are small gaps)
      Reviewers: bgamari, austin, hvr, erikd, simonmar
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3953
  6. 15 Sep, 2017 1 commit
  7. 27 Jun, 2017 1 commit
  8. 21 Apr, 2017 1 commit
    • Ben Gamari's avatar
      base: Fix hWaitForInput with timeout on POSIX · e5732d2a
      Ben Gamari authored
      This was previously broken (#13252) by
      f46369b8, which ported the fdReady
      function from `select` to `poll` and in so doing dropping support for
      timeouts. Unfortunately, while `select` tells us the amount of time not
      slept (on Linux anyways; it turns out this is implementation dependent),
      `poll` does not give us this luxury. Consequently, we manually need to
      track time slept in this case.
      Unfortunately, portably measuring time is hard. Ideally we would use
      `clock_gettime` with the monotonic clock here, but sadly this isn't
      supported on most versions of Darwin. Consequently, we instead use
      `gettimeofday`, running the risk of system time changes messing us up.
      Test Plan: Validate
      Reviewers: simonmar, austin, hvr
      Reviewed By: simonmar
      Subscribers: rwbarton, thomie
      GHC Trac Issues: #13252
      Differential Revision: https://phabricator.haskell.org/D3473
  9. 02 Dec, 2016 1 commit
    • Simon Marlow's avatar
      fdReady: use poll() instead of select() · f46369b8
      Simon Marlow authored
      select() is limited to 1024 file descriptors.  This actually blew up
      in a very hard-to-debug way in our production system when using the
      hinotify package.
      Test Plan:
      libraries/tests pass, paricularly hGetBuf001 which exercises this
      Reviewers: niteria, erikd, austin, hvr, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2785
      GHC Trac Issues: #12912
  10. 12 Jun, 2015 1 commit
  11. 11 Jun, 2015 1 commit
  12. 02 Jul, 2014 1 commit
  13. 08 Jul, 2008 1 commit
  14. 30 Aug, 2007 1 commit
  15. 07 May, 2007 1 commit
    • Simon Marlow's avatar
      FIX: #724 (tee complains if used in a process started by ghc) · d8f90d7f
      Simon Marlow authored
      Now, we only set O_NONBLOCK on file descriptors that we create
      ourselves.  File descriptors that we inherit (stdin, stdout, stderr)
      are kept in blocking mode.  The way we deal with this differs between
      the threaded and non-threaded runtimes:
       - with -threaded, we just make a safe foreign call to read(), which
         may block, but this is ok.
       - without -threaded, we test the descriptor with select() before
         attempting any I/O.  This isn't completely safe - someone else
         might read the data between the select() and the read() - but it's
         a reasonable compromise and doesn't seem to measurably affect
  16. 11 Aug, 2006 1 commit
    • Ross Paterson's avatar
      reduce dependency on ghcconfig.h · 4275eb7f
      Ross Paterson authored
      The only remaining use is in cbits/dirUtils.h, which tests solaris2_HOST_OS
      (Also System.Info uses ghcplatform.h and several modules import MachDeps.h
      to get SIZEOF_* and ALIGNMENT_* from ghcautoconf.h)
  17. 28 Jan, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-01-28 13:36:25 by simonmar] · 2940ff3f
      simonmar authored
      Catch up with updates to platform #defines.
      Generally: use _HOST_ rather than _TARGET_ (except in Cabal where we
      have to retain compatibility with previous GHC versions).
  18. 18 Jan, 2005 1 commit
  19. 03 Sep, 2003 1 commit
  20. 23 Jul, 2002 1 commit
    • sof's avatar
      [project @ 2002-07-23 22:04:36 by sof] · 1089f6c1
      sof authored
      inputReady(): using MsgWaitForMultipleObjects() instead of
      WaitForMultipleObjects() on file handles is nicer from within a
      message pump, but here it is less confusing to use the latter (and
      simply just block message delivery for its duration.)
  21. 13 Feb, 2002 1 commit
  22. 07 Feb, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-02-07 11:13:29 by simonmar] · 91890c68
      simonmar authored
      Various updates after rearranging the directory structure in the
      repository (there wasn't any history worth keeping, and it's better to
      do this now before we go 'live').
      Packages under 'compat' are backwards-compatibility packages which
      should provide an interface equivalent to the current hslibs setup.
      There are a few packages still missing.
  23. 21 Dec, 2001 1 commit
  24. 17 Aug, 2001 1 commit
  25. 31 Jul, 2001 1 commit
  26. 28 Jun, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-06-28 14:15:04 by simonmar] · 4fb94ae5
      simonmar authored
      First cut of the Haskell Core Libraries
      NOTE: it's not meant to be a working snapshot.  The code is just here
      to look at and so the NHC/Hugs guys can start playing around with it.
      There is no build system.  For GHC, the libraries tree is intended to
      be grafted onto an existing fptools/ tree, and the Makefile in
      libraries/core is a quick hack for that setup.  This won't work at the
      moment without the other changes needed in fptools/ghc, which I
      haven't committed because they'll cause breakage.  However, with the
      changes required these sources build a working Prelude and libraries.
      The layout mostly follows the one we agreed on, with one or two minor
      changes; in particular the Data/Array layout probably isn't final
      (there are several choices here).
      The document is in libraries/core/doc as promised.
      The cbits stuff is just a copy of ghc/lib/std/cbits and has
      GHC-specific stuff in it.  We should really separate the
      compiler-specific C support from any compiler-independent C support
      there might be.
      Don't pay too much attention to the portability or stability status
      indicated in the header of each source file at the moment - I haven't
      gone through to make sure they're all consistent and make sense.
      I'm using non-literate source outside of GHC/.  Hope that's ok with
      We need to discuss how the build system is going to work...