[Haskell-cafe] Opening the same file multiple times

[Bulat Ziganshin]

Hello Einar,

Monday, December 12, 2005, 8:43:15 AM, you wrote:

EK> It seems that opening the same file multiple times (one writer
EK> and multiple readers) is not supported at least on *nix with
EK> GHC. I want to use one Handle to use append data till the
EK> end of the file while other Handles perform random access
EK> IO with seeks on the file.

EK> Sharing the same Handle for all the threads is not possible
EK> since they perform seeks and may thus mess each other up.
EK> Hiding the Handle behind a mutex would limit concurrency
EK> more than I like.

may be you can use some tricks, for example read large binary block
from file inside mutex and then parse it in memory?

EK> Thus I wanted to open multiple Handles to the file, but
EK> this seems quite hard. My best guess is to create a function 
EK> like:

EK> #ifdef mingw32_HOST_OS
EK> openUnlocked fn mode = openBinaryFile fn mode
EK> #else
EK> openUnlocked fn mode = withMVar mutex $ do
EK>   h  <- openBinaryFile fn mode
EK>   fd <- handleToFd h
EK>   unlockFile $ fromIntegral fd
EK>   return h

are you read implementation of handleToFd?

-- | Extracts the 'Fd' from a 'Handle'.  This function has the side effect
-- of closing the 'Handle' and flushing its write buffer, if necessary.
handleToFd :: Handle -> IO Fd
handleToFd h = withHandle "handleToFd" h $ \ h_ -> do
  -- converting a Handle into an Fd effectively means
  -- letting go of the Handle; it is put into a closed
  -- state as a result. 
  let fd = haFD h_
  flushWriteBufferOnly h_
  unlockFile (fromIntegral fd)
    -- setting the Handle's fd to (-1) as well as its 'type'
    -- to closed, is enough to disable the finalizer that
    -- eventually is run on the Handle.
  return (h_{haFD= (-1),haType=ClosedHandle}, Fd (fromIntegral fd))


there is also dupHandle but i'm not sure that it will help

another possibility is to work with FDs directly. i can give you a
mini-lib, which emulates Handle-like functions on FDs, but it will be
very inefficient at char-by-char i/o



-- 
Best regards,
 Bulat                            mailto:bulatz at HotPOP.com