threading question for ghc 7.0.2
hello, i'm a bit lost here so i hope s.o. can help me here: seems i have a problem in my code when compiled with ghc-7.0.2: what i try to do: serverside: -listen on a socket and reply to requests client-side: -send a request to that server -wait for a response (with a timeout) any ideas on how i can make this work again without using the -threaded flag? is there is a better way for what i'm trying to achieve? many thanks, oliver the simplified code is available at https://gist.github.com/882770 explanation: the code forks of a lightweight thread (not an OS thread) that will listen for incoming responses. the main thread will go on to push out a message and then wait for the receiver thread to finish. i used to compile my application with the -threaded option but ran into some obscure FFI problems after upgrading from ghc-6.12.3 to ghc-7.0.2. so i tried to remove the -threaded option. but now the message does not get pushed out until the receiver-thread has finished. what is strange to me is that this worked without problems on 6.12.3 but not on 7.0.2. also the behavior is a little different on mac os X with 7.0.2: here i get a "resource vanished (Connection reset by peer)" see the output of the program below ([S] marks output from the main thread, [R] from the receiver thread) compiled on ghc-7.0.2/ubuntu 64bit, without -threaded "running all things..." [R]listening for response... [R]wait for data with timeout:2000 ms ......................................................................................................................................................................................................... [R]no message available [S]pushing out the message [S]sending --> "\EOT\ETX" "[S]going on..." Nothing compiled on ghc-7.0.2/ubuntu 64bit, using -threaded "running all things..." [S]pushing out the message [R]listening for response... [S]sending --> "\EOT\ETX" [R]wait for data with timeout:2000 ms "[S]going on..." ..................................................Just "\ETX\EOT" and...also very strange: when i introduce a putStrLn in the main thread (not a print !) it will work again...only a lot (see code snipped line38: putStrLn "[S]hickup" "running all things..." [S]hickup [R]listening for response... [S]pushing out the message [S]sending --> "\EOT\ETX" [R]wait for data with timeout:2000 ms "[S]going on..." ..................................................Just "\ETX\EOT"
after reading in "GHC's implementation of concurrency" and even more important in the documentation of hWaitForInput it seems clear that my receiver thread blocks and the sender cannot be executed: "NOTE for GHC users: unless you use the -threaded flag, hWaitForInput t where t >= 0 will block all other Haskell threads for the duration of the call. It behaves like a safe foreign call in this respect." even though ghc seems to use a preemptive scheduling strategy, i tried to apply a 'yield' to the receiving thread which worked out quite nicely. now the sender thread gets a chance to run. from the docs: "The yield action allows (forces, in a co-operative multitasking implementation) a context-switch to any other currently runnable threads (if any), and is occasionally useful when implementing concurrency abstractions." still i'm not sure my code is the appropriate solution to the problem i'm trying to solve. and strange to me that my initial solution seemed to be working just fine on ghc 6.x.x. if anybody knows of a better way please let me know! code is again at https://gist.github.com/882770 (including the little 'yield' in line 74) cheers, oliver On Mar 23, 11:47 am, Oliver Mueller <oliver.muel...@gmail.com> wrote:
hello, i'm a bit lost here so i hope s.o. can help me here: seems i have a problem in my code when compiled with ghc-7.0.2:
what i try to do: serverside: -listen on a socket and reply to requests client-side: -send a request to that server -wait for a response (with a timeout)
any ideas on how i can make this work again without using the -threaded flag? is there is a better way for what i'm trying to achieve? many thanks, oliver
the simplified code is available athttps://gist.github.com/882770 explanation: the code forks of a lightweight thread (not an OS thread) that will listen for incoming responses. the main thread will go on to push out a message and then wait for the receiver thread to finish.
i used to compile my application with the -threaded option but ran into some obscure FFI problems after upgrading from ghc-6.12.3 to ghc-7.0.2. so i tried to remove the -threaded option. but now the message does not get pushed out until the receiver-thread has finished. what is strange to me is that this worked without problems on 6.12.3 but not on 7.0.2. also the behavior is a little different on mac os X with 7.0.2: here i get a "resource vanished (Connection reset by peer)"
see the output of the program below ([S] marks output from the main thread, [R] from the receiver thread)
compiled on ghc-7.0.2/ubuntu 64bit, without -threaded
"running all things..." [R]listening for response... [R]wait for data with timeout:2000 ms ........................................................................... ........................................................................... ................................................... [R]no message available [S]pushing out the message [S]sending --> "\EOT\ETX" "[S]going on..." Nothing
compiled on ghc-7.0.2/ubuntu 64bit, using -threaded
"running all things..." [S]pushing out the message [R]listening for response... [S]sending --> "\EOT\ETX" [R]wait for data with timeout:2000 ms "[S]going on..."
..................................................Just "\ETX\EOT"
and...also very strange: when i introduce a putStrLn in the main thread (not a print !) it will work again...only a lot (see code snipped line38: putStrLn "[S]hickup"
"running all things..." [S]hickup [R]listening for response... [S]pushing out the message [S]sending --> "\EOT\ETX" [R]wait for data with timeout:2000 ms "[S]going on..." ..................................................Just "\ETX\EOT"
_______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe
On Thu, Mar 24, 2011 at 9:53 AM, oliver mueller <oliver.mueller@gmail.com> wrote:
if anybody knows of a better way please let me know!
I'd recommending trying to fix your "obscure FFI problems" re: the threaded RTS and go back to using that. Switching concurrency off altogether is a curious response to dealing with an issue in multithreading, and you may not be doing yourself any favours in the long-term by piling on workarounds to get back the semantics you actually want. G -- Gregory Collins <greg@gregorycollins.net>
you are right that i need to fix the FFI problems. but coming back to the threading stuff i do in my haskell code: do i really need to use the threaded runtime here? from the ghc-docs for the -threaded flag: "Note that you do not need -threaded in order to use concurrency; the single-threaded runtime supports concurrency between Haskell threads just fine." as i understand it i am not "switching off concurrency" as you said. I suppose it is not needed for the haskell part. of course then there might be problems when i call into libraries that make use of FFI and need a threaded runtime. e.g. a call to hGetBufNonBlocking. i found a strange note in the docs for windows: "NOTE: on Windows, this function does not work correctly" how can you tell if the -threaded option is necessary if you use other libraries? and what about ghci...what is the default here? in any case i'd really like to figure out the correct approach that is portable (Mac/Linux/Windows) since i need to deploy to all those platforms. oliver On Mar 24, 11:19 am, Gregory Collins <g...@gregorycollins.net> wrote:
On Thu, Mar 24, 2011 at 9:53 AM, oliver mueller
<oliver.muel...@gmail.com> wrote:
if anybody knows of a better way please let me know!
I'd recommending trying to fix your "obscure FFI problems" re: the threaded RTS and go back to using that. Switching concurrency off altogether is a curious response to dealing with an issue in multithreading, and you may not be doing yourself any favours in the long-term by piling on workarounds to get back the semantics you actually want.
G -- Gregory Collins <g...@gregorycollins.net>
_______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe
participants (3)
-
Gregory Collins -
oliver mueller -
Oliver Mueller