[darcs-users] [patch385] Resolve issue1942: Fix an IO interleaving bug in old-f...

Eric Kow kowey at darcs.net
Sat Sep 4 10:10:02 UTC 2010

So why don't hashed repositories suffer from issue1942?
Is it just by virtue of being able to treat the current
repository as a source for hashed files that we'd otherwise
have to fetch from the remote one.

Resolve issue1942: Fix an IO interleaving bug in old-fashioned readRepo.
>            parse2 :: RepoPatch p => PatchInfo -> FilePath
>                                  -> IO (Sealed (PatchInfoAnd p C(x)))
> -          parse2 i fn = do ps <- gzFetchFilePS fn Cachable
> -                           return $ hopefullyNoParseError i (toPath fn) (readPatch ps)
> -          hopefullyNoParseError :: PatchInfo -> String
> -                                -> Maybe (Sealed (Named a1dr C(x)), b)
> -                                -> Sealed (PatchInfoAnd a1dr C(x))
> -          hopefullyNoParseError i _ (Just (Sealed x, _)) =
> -              seal $ patchInfoAndPatch i $ actually x
> -          hopefullyNoParseError i s Nothing =
> -              seal $ patchInfoAndPatch i $ unavailable $ "Couldn't parse file "++s

> +          parse2 i fn = do ps <- unsafeInterleaveIO $ gzFetchFilePS fn Cachable
> +                           Sealed p <- return $ hopefullyNoParseError (toPath fn) (readPatch ps)
> +                           return $ seal $ patchInfoAndPatch i p
> +          hopefullyNoParseError :: String -> Maybe (Sealed (Named a1dr C(x)), b)
> +                                -> Sealed (Hopefully (Named a1dr) C(x))
> +          hopefullyNoParseError _ (Just (Sealed x, _)) = seal $ actually x
> +          hopefullyNoParseError s Nothing = seal $ unavailable $ "Couldn't parse file "++s

OK, two changes:

1. Use of unsafeInterleaveIO to defer gzFetchFilePS until the
   ByteString it produces is actually demanded (by readPatch,
   and I guess walking up to whoever is really using the output of
   readPatch, and so on).  And if I understand correctly, in
   practice (darcs pull), we actually do have cases where we
   don't actually use the remote patch file in question
   (I guess where don't try to commute or present remote patches)

   What are the risks involved in this particular use of
   unsafeInterleaveIO, of not controlling when the file
   fetching happens? What if there are a lot of patches
   to potentially fetch?
2. Shuffling the patchInfoAndPatch out of hopefullyNoParseError
   Aside from a refactor, what does this accomplish?

Hmm, I still have an embarrassingly fuzzy grasp of laziness, but
I suspect I'm due for an ah-hah-nothing-to-it moment.  Or that's
maybe too optimistic.

Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
For a faster response, try +44 (0)1273 64 2905 or
xmpp:kowey at jabber.fr (Jabber or Google Talk only)

More information about the darcs-users mailing list