Persistent Threads & Synchronisation

[Matthew Tylee Atkinson]

On Sun, 26 Nov 2006 19:38:20 +0000, Dennis Lee Bieber wrote:
> 	Methods defined in a thread class but called from outside the
> running thread run in the environment of the caller, not as part of the
> thread (and if the method manipulates state you may run into conflicts).

Thanks very much; I'd arrived at this conclusion, but didn't know how to fix the
situation.

> 	You CAN NOT restart threads... You have to recreate the whole thread
> object. .start() can only be called ONCE on any thread object.

That clears a lot up.

> 	clean(), next(), and quit() will be called by the main thread as
> needed. The "preview thread" does nothing except wait for a command on
> the queue, then performs the operation requested. The main thread will
> have to ensure it calls the next() and clean() methods in proper
> sequence.

Excellent; thanks for the example.

> (How the main thread is informed of completion is something I
> don't know from your post).

Currently, I am using locks (as in threading.Lock()).

> 	If you /need/ to have overlapped downloads and cleanups, you will
> need TWO threads, and much more complex interlocking.

I don't, but thanks for the advice.

best regards,


-- 
Matthew Tylee Atkinson <matthew at agrip.org.uk>