December 2005 - Haskell-Cafe

RE: [Haskell-cafe] STM commit hooks
by Simon Marlow 12 Dec '05

12 Dec '05

On 29 November 2005 12:40, Einar Karttunen wrote: > Hello > > I have been playing with STM and want to log transactions to disk. > Defining a logging function like: > > log h act = unsafeIOToSTM $ hPrint h act > > works most the time. Aborts can be handled with: > > abort h = log h Abort >> retry > atomic' h act = atomically (act `orElse` abort h) > > But is it possible to handle a commit? > > commit h = unsafeIOToSTM (hPrint h Commit >> hSync h) > atomically2 h act = atomically ((act >> commit h) `orElse` abort h) > > This won't work because the transaction is validated and > maybe aborted after the commit is logged to disk. > > Another alternative would be: > > atomically3 h act = atomically (act `orElse` abort h) >> atomically > (commit h) If I'm understanding you correctly, what you need is to log the commit operation before another thread commits and logs a transaction. So you just need to close this race hole at the '>>' in the above definition. How about this: log_lock <- newTMVar () atomically3 h act = do atomically (do act; takeTMVar log_lock `orElse` abort h) hPrint h Commit atomically (putTMVar log_lock ()) does that work? Cheers, Simon

2 1

STM commit hooks
by Einar Karttunen 12 Dec '05

12 Dec '05

Hello I have been playing with STM and want to log transactions to disk. Defining a logging function like: log h act = unsafeIOToSTM $ hPrint h act works most the time. Aborts can be handled with: abort h = log h Abort >> retry atomic' h act = atomically (act `orElse` abort h) But is it possible to handle a commit? commit h = unsafeIOToSTM (hPrint h Commit >> hSync h) atomically2 h act = atomically ((act >> commit h) `orElse` abort h) This won't work because the transaction is validated and maybe aborted after the commit is logged to disk. Another alternative would be: atomically3 h act = atomically (act `orElse` abort h) >> atomically (commit h) But this does not work either. Given Trx1 and Trx2, the following may occur: 1) Trx1 commits <thread switch> 2) Trx2 commits (and depends on Trx1) 3) Trx2 commit is logged to disk <system crash> This means that the log would be inconsistent. Is there a way to implement the commit that works? - Einar Karttunen

2 1

RE: [Haskell-cafe] STM, orElse and timed read from a channel
by Simon Marlow 12 Dec '05

12 Dec '05

threadDelay is IO-only; there's no way to use threadDelay in an STM transaction. For example, if you want to wait for a TVar to go from Nothing to Just x with a timeout, you could do this: readOrTimeout :: TVar (Maybe a) -> Int -> STM (Maybe a) readOrTimeout t secs = do timeout <- registerTimeout secs let check_timeout = do b <- readTVar timeout if b then return Nothing else retry check_t = do m <- readTVar t case m of Nothing -> retry Just x -> return x atomically $ check_timeout `orElse` check_t Cheers, Simon On 29 November 2005 10:11, Joel Reymont wrote: > Simon, > > How is this easier than just calling threadDelay? > > Ideally, I would be looking for something like reading from a TVar > with a timeout. So that you either get a Nothing (timeout) or the > value from the TVar. Can I implement it using the GHC timeout thread? > > Thanks, Joel > > On Nov 29, 2005, at 9:20 AM, Simon Marlow wrote: > >> Interestingly, GHC already has a timeout thread - the I/O manager >> thread handles threadDelay too. It wouldn't be too hard to adapt it >> to do STM timeouts too, with a function like >> >> registerTimeout :: Int -> STM (TVar Bool) >> >> and you wait for your timeout by waiting for the TVar to contain >> True.

3 4

Existentially-quantified constructors, Eq and Show
by Joel Reymont 12 Dec '05

12 Dec '05

Folks, Is there a less verbose way of doing this: data State a = Start | Stop | (Show a, Eq a) => State a instance Eq a => Eq (State a) where (State a) == (State b) = a == b Start == Start = True Stop == Stop = True instance Show a => Show (State a) where show (State a) = show a show Start = "Start" show Stop = "Stop" Thanks, Joel -- http://wagerlabs.com/

9 18

Re: [Haskell-cafe] Opening the same file multiple times
by Donn Cave 12 Dec '05

12 Dec '05

Quoth Einar Karttunen <ekarttun(a)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 module Main (main) where import IO (openFile, IOMode(..), SeekMode(..), hPutStr, hSeek, hGetLine) import System (getArgs) main = do af <- openFile "z" AppendMode sf <- openFile "z" ReadMode hPutStr af "append this line\n" hSeek sf AbsoluteSeek 40 hGetLine sf >>= print hPutStr af "append this line\n" hSeek sf AbsoluteSeek 60 hGetLine sf >>= print (It works for me, with hugs on a more or less UNIX-like platform.) Donn Cave, donn(a)drizzle.com | Sharing the same Handle for all the threads is not possible | since they perform seeks and may thus mess each other up. | Hiding the Handle behind a mutex would limit concurrency | more than I like. | | Thus I wanted to open multiple Handles to the file, but | this seems quite hard. My best guess is to create a function | like: | | #ifdef mingw32_HOST_OS | openUnlocked fn mode = openBinaryFile fn mode | #else | openUnlocked fn mode = withMVar mutex $ do | h <- openBinaryFile fn mode | fd <- handleToFd h | unlockFile $ fromIntegral fd | return h | | {-# NOINLINE mutes #-} | mutex = unsafePerformIO $ newMVar () | #endif | | Is there really no simpler solution?

2 1

Tail-call optimization
by Joel Reymont 11 Dec '05

11 Dec '05

I always wandered, does ghc do tail-call optimization? Would it optimize the two variants of the function below or just the first one? --- Proper? writeLoop :: (Event a -> IO ()) -> Handle -> (SSL, BIO, BIO) -> IO () writeLoop post h ssl = do handle (\e -> post $ NetworkError e) $ do cmd <- read h ssl post $! Cmd $! cmd writeLoop post h ssl --- Bad? writeLoop :: (Event a -> IO ()) -> Handle -> (SSL, BIO, BIO) -> IO () writeLoop post h ssl = do handle (\e -> post $ NetworkError e) $ do cmd <- read h ssl post $! Cmd $! cmd writeLoop post h ssl Thanks, Joel -- http://wagerlabs.com/

4 5

Re: [Haskell-cafe] [Newbie] Why or why not haskell ?
by Donn Cave 11 Dec '05

11 Dec '05

Quoth Tomasz Zielonka <tomasz.zielonka(a)gmail.com>: ... | What I fear about the future of Haskell, is that we will have so many | libraries FFIying to C, that our programs will crash as often as | programs written in C. | | FFI is necessary, but IMO it shouldn't be used when it doesn't have | to be. I spent some time recently trying to make a trivial text analysis run fast enough to use it on large data sets. I eventually achieved a satisfactory result - twice as fast as simple awk and Python versions. Of course I used the FPS packed string library functions, and I spent a lot of time profiling. One thing I found that way, is that FPS.words iterates over the string byte by byte, in Haskell, but there's a function (breakSpace?) that calls C to find the next space - and it's a lot faster. On the other extreme, I have found it surprisingly painless to call OpenLDAP functions from Haskell, which means I don't have to write my own LDAP protocol in Haskell, but also SASL, SSL, GSSAPI and Kerberos. The effort to do that would be enormous and eventually misguided, not a good thing for Haskell programmers in any way. So -- well, I actually agree with you in principle, but I'm just thinking it depends a lot on when we decide we `have to' use FFI, and in the end the advantages will very often be too compelling. Even for basic data manipulation without Haskell overhead, like FPS. Donn Cave, donn(a)drizzle.com

1 0

Re: [Haskell-cafe] syscall, sigpause and EINTR on Mac OSX
by Donn Cave 11 Dec '05

11 Dec '05

Quoth Joel Reymont <joelr1(a)gmail.com>: ... | My program is currently stuck here. The man pages say that sigpause | will only terminate by being interrupted and EINTR will be the errno. | EINTR is signal 2, the same one that I'm trapping and the one sent | when ^C is pressed. I sure haven't been able to follow all of the ensuing discussion on this, but in case it helps -- EINTR is not a signal, it's an error status from a function that was interrupted by a signal. Just going on this error, the signal may have been SIGINT - or any other signal, such as for example SIGALRM, which could be generated by a timer function (see alarm, setitimer), or SIGCHLD, which could be generated on exit of a child process under certain circumstances. Etc. Obviously the use of signals in this way (timers, for example) has the potential to make your application unsound. It's particularly insidious when it occurs in library functions. Now if you actually have observed that your SIGINT handler was entered at this point, then please ignore me. Donn Cave, donn(a)drizzle.com

2 1

Detecting Cycles in Datastructures
by Tom Hawkins 11 Dec '05

11 Dec '05

In a pure language, is it possible to detect cycles in recursive data structures? For example, is it possible to determine that "cyclic" has a loop? ... data Expr = Constant Int | Addition Expr Expr cyclic :: Expr cyclic = Addition (Constant 1) cyclic Or phased differently, is it possible to make "Expr" an instance of "Eq" such that cyclic == cyclic is smart enough to avoid a recursive decent? -Tom

14 32

GHCi and threads, was Connecting to a running process (REPL)
by Rohan Drape 10 Dec '05

10 Dec '05

On Tue Dec 6 15:01:45 EST 2005 Tomasz Zielonka wrote: > Unfortunately it seems that forkIO'ed threads are freezed when GHCi is > waiting for command-line input. I bet it would be possible to let > the threads work in the background. I think the current behaviour is > caused by using readline, which is a foreign library. Or it is by > design? I also think this is unfortunate, and would like to know if this can be worked around (ie. I could happily live without readline if that is the issue and it can be switched off). Regards, Rohan

1 0