Is it an error to call hGetLine on a non-blocking Handle?

Alain O'Dea alain.odea at gmail.com
Tue May 6 17:35:15 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue 06 May 2014 04:39:19 PM UTC, Bryan O'Sullivan wrote:
>
> On Mon, May 5, 2014 at 10:04 PM, Alain O'Dea <alain.odea at gmail.com
> <mailto:alain.odea at gmail.com>> wrote:
>
>     I'm trying to get to the bottom of a very tenacious bug in the GHC
>     Builder.
>
>     The details of how this happens are documented separately for
>     reference:
>     https://gist.github.com/AlainODea/dc841046524cd7833da8
>
>     The Handles involved are returned by
>     System.Process.runInteractiveProcess.  They are non-blocking at the
>     Illumos kernel level.
>
>     It appears that maybeFillReadBuffer (called by hGetLine under the
>     hood) treats EAGAIN as an error:
>
>     http://hackage.haskell.org/package/base-4.7.0.0/docs/src/GHC-IO-Handle-Text.html#maybeFillReadBuffer
>
>     Is it expected that runInteractiveProcess would return non-blocking
>     Handles for stdout and stderr?
>
>
> The non-blockingness should be hidden.
>
> Your attempt to follow EAGAIN down the programmatic rabbit hole hasn't
> gotten you nearly far enough, I'm afraid. You stopped at a layer where
> the underlying non-blocking nature of the IO shouldn't be visible, so
> it would be inappropriate to check for EAGAIN there. As you'll notice
> if you follow the breadcrumbs further, it becomes quite difficult to
> spelunk through the various vtables to see what's really going on.
>
> I /think/ that you should be looking at GHC.IO.FD.readRawBufferPtr, as
> that's where the IO is ultimately happening. The trouble is, it
> calls throwErrnoIfMinus1RetryMayBlock, which should already be doing
> the right thing with EAGAIN. Sadly, I don't know what's going wrong
> here, but I'm sure you will need to go down a level or two of
> abstraction from where you are now before you'll find the source of
> the problem.

Thank you Bryan.  I'm probably too low-level with my current DTrace of
syscalls and definitely too high-level in the GHC sources as you have
identified.  I'll find my way to the middle here.

I'll take a look at GHC.IO.FD.readRawBufferPtr and
throwErrorIfMinus1RetryMayBlock.  It appears to be working normally for
most of the operations, but hits a gap somewhere that allows the
ResourceExhausted IOError to leak out.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTaR1TAAoJEP0rIXJNjNSA2UsH/3DrAO9e1TTqwqNUIaBI49Oi
/Aigcq+4DGGC5KjhNHwuISDkjdCsOzoXVrgdS5ujl5ZQkJW9S6Lm6L9TMU5b0vxW
u21r5n2FmZCG6ENDUUxbb9V8/pN6rYgtNB0mXojXnhccDVqwboo5d6ivjjx3jdoC
IkvmnPe0YOtHGHx44RX0U1Q33moa2kDE1+nCalnu80k8zmIK9QvdTD8DDx2aGnIg
A4sZXty5pjO9jVYu02IoCvCIYwLtPoSye681TnMDoplY+UHtrV1eIeDl0fs6HgaV
lfRzEnfnRObvkLOb7sCjLCZ5l8M8mgXZaefAumTLuuRwSYSj2gsAzWvSe88PyTE=
=dqzc
-----END PGP SIGNATURE-----



More information about the Libraries mailing list