[Haskell-cafe] Re: Waiting for thread to finish

[Maurí­cio]

 >>>> After I have spawned a thread with 'forkIO',
 >>>> how can I check if that thread work has
 >>>> finished already?  Or wait for it?

 >>> The best way to do this is using
 >>> Control.Exception.finally: (...)

 >> Changing ugly code for bad performance is not
 >> that usual in Haskell code :(

 > I think you misunderstand Chris' remark. He's
 > saying that MVars and forkIO give you bot clean
 > control, and high performance.

Sorry if I sound rude. I just saw a place for a
small joke, and used it. Chris code is pretty
elegant to what it is supposed to do. However,
knowing if a thread has finished is just 1 bit of
information. There's probably a reason why that
would hurt performance, but I don't understand
it. For most situations, I believe you want to
know when a thread has finished, and have that in
the implementation is probably more efficient than
creating a MVar for each one. Please understand
that I'm not criticising anyone's work, I just
want to understand it better. Threads are a deep
problem with many issues involved, and I have no
proper knowledge of any of them.


 > This code seems quite elegant, for the job you
 > were asking:
 >
 >     import Control.Concurrent
 >     import Control.Exception
 >
 >     main = do
 >         done <- run (print (last [1..100000000]))
 >         print "Waiting...."
 >         takeMVar done
 >         print "OK."
 >      where
 > (...)

Sorry, I don't agree. I try to write things in a
way that when you read it you can get an intuition
on why it's doing what it's doing; even when the
code is for my reading only (which, in Haskell, is
almost always the case). For instance: in the code
I'm writing now, I need to know if threads have
finished since only them I can use the files they
generate. So, instead of checking if threads have
finished, I decided to check if files exist and
are available for writing. When I read 'takeMVar
done', it's difficult to think why you want to
read a value you are never going to use. But, of
course, maybe this is just my prejudice, and if I
understand anything about threads I would have a
different feeling about it.

 > And the lovely thread-ring benchmark, is also very nice:
 >
 > 
http://shootout.alioth.debian.org/gp4/benchmark.php?test=threadring&lang=all
 >
 > (...)

Sorry, I didn't think that's nice either. I read
the description of the task, and it's one where in
the real world you would never use threads to do
it, except for benchmarking threads. Of course,
that is important for many people, like those who
study threads and their implementation. But do you
know of a benchmark where the task is some kind of
situation where you actually get a result faster
by using threads than by using a single thread?

Thanks,
Maurício