On 11/17/05, Joel Reymont <[EMAIL PROTECTED]> wrote:
>
> On Nov 17, 2005, at 1:44 PM, Sebastian Sylvan wrote:
>
> > Are you sure it's safe to kill a thread which has already been killed?
>
> It seems so from the docs.
>
> > Why do you fork off the killing of the threads? Why not just run them
> > in sequence?
>
> Someone said that they read somewhere that killThread can block. I'm
> not gonna point any fingers at musasabi ;-).
>
> > Also, I'd recommend refactoring the code a bit, write a function
> > "parIO" which runs IO computations in parallell and then define
> > timeout in terms of that.
>
> I did this by stealing the timeout/either combinators from the
> Asynchronous Exceptions paper. It did not help a single bit.
>
This is somewhat frustrating for me because I had a very similar (if
not the exact same) issue when writing some test applications for an
FMOD binding. However, all that source code (and so much more) was
lost due to a hard disk failure. I am now struggling to remember what
was the cause, and how I solved.
What I do remember is that the timeout and parIO functions in the
concurrent programming papers I found were NOT correct. killThread did
NOT behave as expected when I killed an already killed thread.
I tried multiple tricks here (including some which required recursive
do-notation) to try to get the parIO function to only kill the *other*
thread.
This could be done by having the two spawned threads take their
computations in an MVar along with the threadID of the other thread.
something like:
parIO f1 f2 = do m <- newEmptyMVar -- result Mvar
mf1 <- newEmptyMVar -- MVar for f1
mf2 <- newEmptyMVar -- MVar for f2
-- fork worker threads
t1 <- forkIO (child m mf1)
t2 <- forkIO (child m mf2)
-- pass computations and threadID to worker threads
putMVar mf1 (t2, f1)
putMVar mf2 (t1, f2)
-- return result
takeMVar m
where child m mf = do (tid, f) <- takeMVar mf
x <- f
putMVar m x
killThread tid
timeout t f = threadDelay (round (t * 1e6)) `parIO` f
As I remember another solution I came up with was to wrap the "child"
function body in a catch statement. The child function was just a
helper function that ran a computation and put its result in an MVar.
I *think* the problem *may* have been that when an FFI function got
"ThreadKilled" exception asynchrounously that got bubbled up to the
parIO thread for some reason.
/S
--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
