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 / [EMAIL PROTECTED] 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 _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
