Rob Vesse <[email protected]> writes: > Having looked over the code again the only obvious possible issue I can > see is the following scenario: > > 1 - App launches a reader thread using a thread pool - reader is assigned > to thread X > 2 - Reader thread fails and releases thread X to the pool > 3 - App launches a writer thread using a thread pool - writer is assigned > to thread X > 4 - Writer never detects the reader failure because it is on the same > thread as the reader originally was and so the writer thread is considered > alive
I don't think that's what's going on in my test case, but perhaps I
misunderstand the threading model. I don't have a lot of experience
writing multi-threaded apps.
It looks to me simply like the iterator expects to be called at least
once by the writer, in order to establish the identity of the writing
thread, but if the writing thread dies before it ever calls the
iterator, the iterator is stuck.
As the code stands today, there's nothing you can do on the reader to
abort. Calling .close() on the iterator has no effect.
FWIW, I made the following changes in the loop:
// If the producer thread died and did not call finish() then
declare this pipe to be "broken"
// Since check is after the break, we will drain as much as
possible out of the queue before throwing this exception
if (writeSide != null && !writeSide.isAlive() && !closedByWriter)
{
closedByReader = true ;
}
if (closedByReader) {
throw new RiotException("Write end dead") ;
}
Now calling rdfIter.close() in the exception handler on the writing
thread seems to work around my immediate problem, though I suppose I
could be introducing other problems I don't know about...
Be seeing you,
norm
--
Norman Walsh <[email protected]> | Four things come not back: the spoken
http://nwalsh.com/ | word, the sped arrow, time past, the
| neglected opportunity.--Omar Ibnal-Halif
signature.asc
Description: PGP signature
