Thread-backed handles: thread blocked indefinitely in an MVar
marlowsd at gmail.com
Tue Jun 22 17:02:26 EDT 2010
On 22/06/10 12:43, Dimitry Golubovsky wrote:
> On Tue, Jun 22, 2010 at 4:31 AM, Simon Marlow<marlowsd at gmail.com> wrote:
>> So the problem is that fillReadBuffer has to return 0 to indicate EOF, but
>> you are killing the slave thread as soon as it has reached the end of the
>> stream. So you get one call to fillReadBuffer that returns the data up to
>> the end of the stream, and the next call that should return 0 blocks on the
>> Chan indefinitely because the slave thread has already been killed.
> Thanks for your reply.
> Updated paste: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=26455
> I enclosed readChan in a catchException call which seems to have cured
> the problem: it just simulates EOF on the handle if the thread is
> blocked (channel vanished). Interestingly that in the failing version,
> handle closing was done in a separate thread (thread 3), but in the
> updated version it was the same thread 1.
That will work, but very very slowly, because the exception isn't raised
until a full GC runs and discovers the thread to be unreachable. I
suggest instead having some state to indicate that EOF has been reached.
More information about the Glasgow-haskell-users