[darcs-devel] Moving system code to Haskell

Juliusz Chroboczek Juliusz.Chroboczek at pps.jussieu.fr
Sun Aug 28 15:13:53 PDT 2005


Ian, this is important.  People are relying on Darcs.  Darcs is
allowed to have all sorts of bugs -- but it must never, ever eat your
data.

> 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.

As a general rule, I think that moving low-level filesystem access
code to Haskell is a mistake; the people likely to find bugs in this
kind of code are not necessarily Haskell cognoscenti.

In this particular case:

1. maybe_relink is probably the most fragile piece of code in Darcs.
To my knowledge, it is the only place where we don't take a lock over
a repository that must not be changed (there are good reasons for
that: taking 2 locks simultaneously is deadlock-prone, and we might
not have write access to the repository we're linking against).  If
there's an undetected race condition while relinking, Darcs will
happily destroy patch files.

This code is horribly boring, and makes me nervous.  I've done enough
work on it to be confident enough to use it for my own repositories,
and I'm not going to do this work again.  If you refuse to revert to
the older version, I'd rather you removed the relinking functionality
altogether.

(By the way, this is the second time that I'm offering to remove
functionality that I personally implemented in order to fit your
particular tastes.  Not that I have much choice.)

2. atomic_create is used throughout Darcs to implement locks.  It used
to be unsafe over NFS; the version I wrote (careful_atomic_create) is
believed to be safe over NFSv2, NFSv3 including buggy Linux NFS clients.

This code is much simpler than the previous case, so I would be
willing to review your new implementation (and related bits of the GHC
libraries) for NFS safety.  However, I would be more confortable if
you reverted to the C version.

> I assume there's no library commonly available that has the
> functionality we want, by the way?

Not to my knowledge.

> 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?

It wouldn't save any work.  Conscientious project maintainers would
still need to review our library for safety.  (This is related to the
fact that conscientious project maintainers would need to review the
GHC library for safety if they chose to implement such functionality
in Haskell.)

                                        Juliusz




More information about the darcs-devel mailing list