Re: [Haskell-cafe] Opening the same file multiple times
Quoth Einar Karttunen <ekarttun@cs.helsinki.fi>: | On 11.12 22:26, Donn Cave wrote: | > Quoth Einar Karttunen <ekarttun@cs.helsinki.fi>: | > | It seems that opening the same file multiple times (one writer | > | and multiple readers) is not supported at least on *nix with | > | GHC. I want to use one Handle to use append data till the | > | end of the file while other Handles perform random access | > | IO with seeks on the file. | > | > How is it not supported? What happens with something like this ... | *** Exception: z: openFile: resource busy (file is locked) Oh. Well, that's unfortunate, but at least I see it is documented. I guess that explains why your solution uses unlockFile. I suppose you might be able to use Posix.IO functions instead, but that would probably be even more trouble than your work-around. Donn Cave, donn@drizzle.com
Quoth Einar Karttunen <ekarttun@cs.helsinki.fi>: ... | *** Exception: z: openFile: resource busy (file is locked) Now that I have access to a platform where ghc builds, I can duplicate your results - and in case it helps, here's another work-around. Apparently this "feature" uses POSIX filesystem locks, because it appears that we can exploit the brain-damaged semantics of that system: when a process closes a file, all its locks are cleared - whether they were acquired through that file descriptor or another unrelated open. It may be the first time anyone has ever benefited from this! import IO main = do fc <- openFile "z" ReadMode -- sacrificial handle fr <- openFile "z" ReadMode hClose fc fa <- openFile "z" AppendMode hPutStr fa "append this line\n" hGetLine fr >>= print If you may need to open more read handles later, you can add another extra close after the append handle. Of course there's a risk that the authors of ghc may notice that we're doing this and come up with a way to thwart it, but it seems to me that between interfering with legitimate applications and not working reliably anyway, there'd be a case for letting go of this notion altogether. Donn Cave, donn@drizzle.com
On Mon, 2005-12-12 at 09:52 -0800, Donn Cave wrote:
Of course there's a risk that the authors of ghc may notice that we're doing this and come up with a way to thwart it, but it seems to me that between interfering with legitimate applications and not working reliably anyway, there'd be a case for letting go of this notion altogether.
Except that it is specified to work this way in the Haskell Report. Instead of changing the semantics of the standard libraries what you want is a back door to allow the alternative semantics that you want. Even better would be to provide a supported api for opening files without locking. Duncan
On Mon, 12 Dec 2005, Duncan Coutts wrote:
On Mon, 2005-12-12 at 09:52 -0800, Donn Cave wrote:
Of course there's a risk that the authors of ghc may notice that we're doing this and come up with a way to thwart it, but it seems to me that between interfering with legitimate applications and not working reliably anyway, there'd be a case for letting go of this notion altogether.
Except that it is specified to work this way in the Haskell Report.
Instead of changing the semantics of the standard libraries what you want is a back door to allow the alternative semantics that you want. Even better would be to provide a supported api for opening files without locking.
Actually I think I would prefer that the semantics change. A work-around would be good, and its existence would help publicize the problem with openFile, but changing openFile would be better for everyone, I suspect. (Apparently it may have been so specified in Haskell 98, up to April 2001?) Donn Cave, donn@drizzle.com
participants (2)
-
Donn Cave -
Duncan Coutts