RFC: ghc's dynamic linker

Simon Marlow simonmar@microsoft.com
Wed, 28 Aug 2002 10:14:17 +0100


> On Tue, Aug 27, 2002 at 05:19:15 +0100, Simon Marlow wrote:
>=20
> > 'haskell98' packages, just like GHCi does.  It *almost* works to do
> > this, except that you get strange effects, one of which is=20
> that you have
> > two copies of stdout each with their own buffer.
>=20
> If it's not too much trouble, do you mind explaining why this is
> so?  It's just to satisfy my curiosity; don't worry if it's too
> long-winded or contains really heavy wizardry :).

It's quite simple: there will be one stdout Handle in your program, and
one in the base package that has been loaded.  Each is a separate Handle
in its own right, with its own buffer, although they both point to the
same underlying file descriptor.  This can lead to strange effects
because different parts of the program will be using different stdout
handles, and the output might not be ordered in the way you expect.

For functions, it's ok to have two identical copies, because you can't
observe which one is being used.  For most normal CAFs, the same is true
except that the program might take longer to run than expected.  You
would be able to observe that there are two copies of the random number
stream from the Random library, however.

> You've already got the symbol table in memory though, right?  Is
> it absolutely necessary to re-read the binary?

not sure what you mean here.  The symbol table isn't normally read when
a binary is executed - the same binary works fine after it is stripped,
after all.

Cheers,
	Simon