[Haskell-cafe] How does RTS judge that a STM transaction is blocked?

Magicloud Magiclouds magicloud.magiclouds at gmail.com
Thu Feb 5 03:46:22 UTC 2015


Thank you. That is why I am confused. Does it mean the read thread is dead
before waitForEvent?

On Thu, Feb 5, 2015 at 11:42 AM, Ryan Yates <fryguybob at gmail.com> wrote:

> When you get the "thread blocked indefinitely in an STM transaction" it is
> the result of the garbage collector finding no references to the TVars that
> a 'retry'ing or blocked transaction.  If there are no references to those
> TVars then there is no way for that transaction to ever succeed.  I don't
> know if that helps.
>
> On Wed, Feb 4, 2015 at 7:59 AM, Magicloud Magiclouds <
> magicloud.magiclouds at gmail.com> wrote:
>
>> Hi,
>>
>>   I met an issue while I was using xhb. When a certain property of root
>> window being changed, it was supposed to give me an AccessError. But
>> actually I got "thread blocked indefinitely in an STM transaction" when
>> I waitForEvent.
>>
>>   AFAIK, in xhb, it forks a thread to read what X server sends. Then
>> parse and put it into a TChan. waitForEvent reads from the TChan.
>>
>>   It is reasonable to me that if X server did not send anything, then
>> waitForEvent would be blocked. But apparently there are some other policies
>> in RTS.
>>
>>   So what is that? And how should I debug it?
>>
>> --
>> 竹密岂妨流水过
>> 山高哪阻野云飞
>>
>> And for G+, please use magiclouds#gmail.com.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>


-- 
竹密岂妨流水过
山高哪阻野云飞

And for G+, please use magiclouds#gmail.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20150205/3fe94289/attachment.html>


More information about the Haskell-Cafe mailing list