Could you send a full example we can compile and test? This is only a fragment. bulat.ziganshin:

Hello glasgow-haskell-users,

i've looked for this bug in Trac but don't found anything. so:

startGUI action = runInBoundThread $ do unsafeInitGUIForThreadedRTS myThreadId >>= writeIORef guiThread action >>= widgetShowAll mainGUI

guiThread = unsafePerformIO$ newIORef$ error "undefined GUI::guiThread"

Later in the same thread i ask for myThreadId and get different value. interesting that value returned in startGUI is 23 while later values are about 7000. probably this reflects total amount of threads created so far

so that's the problem. Win API call returns constant thread number (that looks natural since the thread is bound). so either:

1) it's feature - please mention this in docs 2) it was fixed since 6.6.1 3) we need full-scale bugreport using 6.10.2

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Bulat Ziganshin wrote:

Hello glasgow-haskell-users,

i've looked for this bug in Trac but don't found anything. so:

startGUI action = runInBoundThread $ do unsafeInitGUIForThreadedRTS myThreadId >>= writeIORef guiThread action >>= widgetShowAll mainGUI

guiThread = unsafePerformIO$ newIORef$ error "undefined GUI::guiThread"

Later in the same thread i ask for myThreadId and get different value.

What does "same thread" mean? I'll risk a guess. mainGUI is a safe foreign call that executes a loop on the C side; all future actions that you see and consider to be in the same thread are actually callbacks from C to Haskell. But in GHC's RTS, a new Haskell thread is created for each such callback, with a new thread id. So myThreadId returns varying numbers, leading to the effect that you described. So it's not a bug, although it should be better documented. It's not possible for the RTS to track which Haskell thread a callback was originally registered from (at best it could remember which thread created the original wrapper), and in any case that thread may be dead already, or running Haskell code at the time the callback comes, so I think that the current behaviour is quite sane. regards, Bertram