[darcs-devel] Moving system code to Haskell

Ian Lynagh igloo at earth.li
Sun Aug 28 14:01:15 PDT 2005


On Sun, Aug 28, 2005 at 09:17:47PM +0200, Juliusz Chroboczek wrote:
> 
> 3. While there are strong guarantees about the atomicity behaviour of
> system calls (Unix manual section 2), there are no such guarantees
> about library functions (Unix manual section 3) or Haskell library
> functions.  While I'm willing to take your word that createLink is
> just a call to link(2), I'm curious to know whether you have actually
> checked that this is indeed the case, and intend to keep checking at
> every new release of GHC.

createLink is in System.Posix, so I'm sure if you were to ask
Simon Marlow / libraries at haskell.org then you would be told that it
would be a bug if it did not provide the atomicity guarantees that
POSIX does.

Just because these guarantees aren't actually written down somewhere
doesn't mean they aren't effectively there.

> > While it may not be explicitly written down everywhere, I think we can
> > assume that we will get the same atomicity guarantees as we would in C.
> 
> Sorry, Ian.  ``I think we can assume'' is just not good enough.

That's just a cross between a figure of speech and you not being
explicit about what you are worrying about.

> > Ultimately GHC is just going to be calling those same C functions
> > anyway,
> 
> Not necessarily.  Have a look at openFile in older versions of GHC.

I think I'm missing your point. At a quick look it looks like openFile
in ghc 5 is calling C's open.

> > I'd really like to rid darcs of C code completely,
> 
> Why?  (You do have sound technical reasons for that change, right?)

I gave some in another message in this thread, but that subthread wasn't
CCed to you so you might have missed it if you aren't reading this on
d-d?


I do take your points, but on the other hand there are my points in the
other post along with 3 bugs in the C code or its use.

As I say in the other message, I'd like to know exactly which functions
you'd like to remain in C. If it's just these three then I think I'm
erring on the side of moving them back, despite my C removal ambitions.


I assume there's no library commonly available that has the
functionality we want, by the way? That way we wouldn't have to carry
the burden of making sure it was all safe and correct ourselves, and may
have it work more portably too.

And perhaps if not it would be worthwhile to split them off into a small
C lib (probably also bundled with the darcs source for the forseeable
future) so that other projects can make use of them without reinventing
the wheel?


Thanks
Ian





More information about the darcs-devel mailing list