From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-09-28T03:29:02+09:00
Subject: Re: Threading and Deadlock

------=_Part_36743_21314290.1159381738216
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 9/27/06, Jordan McKible <jmckible@gmail.com> wrote:
>
>  > #fill contains a statement that can sleep for multiple
> > minutes
> > holding a mutex lock, but fortunately appears not to be reachable.
>
> This is by design - in order to not be constantly retrieving feeds (that
> seems a little exessive for a feed reader) I want to have a break
> between refills


As coded, your design waits for multiple minutes, then (presumably) fires
off a few thousand HTTP requests, then goes right back to sleep, *holding
the mutex that your worker threads need to run.* Don't do that.

Now of course when you have a loop in crawl, I assume you'll have it grab
the lock, then run until the queue is consumed, which will block the fill
thread at the Mutex#synchronize call (assuming you're lucky enough for one
of the workers to get scheduled before the fill thread tries to go back to
sleep. If that's what you want, you really don't need threads in this app.

If you really think you need to do this with threads, then you need to
re-analyze your synchronization sets, and possibly define a few more
mutexes. Also, you mentioned a capturable external latency in the fill
operation, but not in the crawl. Is there one?

------=_Part_36743_21314290.1159381738216--