Re: [Haskell-cafe] Threads and hGetLine

2012-05-02 Thread Johannes Waldmann

 There are two threads, one which is waits on input via 
 hGetLine
 and another, which should terminate this thread or close this handle.

like this? The trick is to fork the blocking call (hGetLine)
and wait on an MVar. That way, the kill signal can be handled:

{-# language PatternSignatures #-}

import Control.Concurrent
import Control.Concurrent.MVar
import Control.Exception
import System.IO

main = do
  pid - forkIO $ do
s - wawiter
putStrLn s
  threadDelay $ 5 * 10^6
  killThread pid
  
waiter = do  
  v - newEmptyMVar
  forkIO $ do s - hGetLine stdin ; putMVar v s
  readMVar v `Control.Exception.catch` 
\ (e :: AsyncException ) -  return killed

PS: and I refuse to use the ScopedTypeVariables pragma
since obviously there are no type variables.



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Threads and hGetLine

2012-04-28 Thread H. M.

Hello,

The simplified problem:

There are two threads, one which is waits on input via 
hGetLine
and another, which should terminate this thread or close this handle.

hClose
as well as
killThread
doesn't seem to work, caused by the fact, that the thread is blocked until input
is availiable.

Hopefully you have some solution how to kill the thread and/or close the handle
and/or have some other idea to get the lined input in the other thread.

--
Thanks in advance
H.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Threads and hGetLine

2012-04-28 Thread Alvaro Gutierrez
Hi --

I am not well-versed in Haskell-specific multi-threading, but usually there
is a better way to do what you want that does not involve killing threads
(which in most cases is bad idea.)

For example, using non-blocking IO and e.g. a synchronized condition
variable; hWaitForInput might work in your case, or something like the
following: http://hpaste.org/52742

Nevertheless, as a guess, I think you may want to try using closeFdWith,
perhaps combined with a call to threadWaitRead before actually calling
hGetLine. The wrinkle is that those operate on file descriptors instead of
handles, but there are fdToHandle/mkHandleFromFD to bridge the gap.

Hope that helps,
 Alvaro










On Sat, Apr 28, 2012 at 2:23 PM, H. M. h._h._...@hotmail.com wrote:


 Hello,

 The simplified problem:

 There are two threads, one which is waits on input via
 hGetLine
 and another, which should terminate this thread or close this handle.

 hClose
 as well as
 killThread
 doesn't seem to work, caused by the fact, that the thread is blocked until
 input
 is availiable.

 Hopefully you have some solution how to kill the thread and/or close the
 handle
 and/or have some other idea to get the lined input in the other thread.

 --
 Thanks in advance
 H.
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Threads and hGetLine

2012-04-28 Thread Joey Adams
On Sat, Apr 28, 2012 at 2:23 PM, H. M. h._h._...@hotmail.com wrote:
 There are two threads, one which is waits on input via
 hGetLine
 and another, which should terminate this thread or close this handle.

 hClose
 as well as
 killThread
 doesn't seem to work, caused by the fact, that the thread is blocked until 
 input
 is availiable.

What OS?  GHC currently doesn't have proper IO manager support for
Windows.  On Windows, IO is performed through FFI calls.  An FFI call
masks asynchronous exceptions (C code generally doesn't expect to be
interrupted at arbitrary points in time).  If another thread tries to
`killThread` the thread waiting for input, the exception will not be
received until the FFI call completes.  This means both threads will
hang.

-Joey

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe