Cool. Thanks for the tip. You wouldn't happen to have any publicly
available examples? Couldn't hurt to see someone else's layout so I
can be sure I have the best structure for mine.
-- Mike
On Mon, Jun 10 @ 11:30, Tim Peters wrote:
> BTW, if you want to run threads with unittest, I expect you'll have to
> ensure that only the thread that starts unittest reports errors to unittest.
> I'll call that "the main thread". You should be aware that if a non-main
> thread dies, unittest won't know that. A common problem in the threaded
> tests PLabs has written is that a thread dies an ignoble death but unittest
> goes on regardless and says "ok!" at the end; if you didn't stare at all the
> output, you never would have known something went wrong.
>
> So wrap the body of your thread's work in a catch-all try/except, and if
> anything goes wrong communicate that back to the main thread. For example,
> a Queue object (one or more) could work nicely for this.
`-> (tim.one)
--
Michael Gilfix
mgilfix@eecs.tufts.edu
For my gpg public key:
http://www.eecs.tufts.edu/~mgilfix/contact.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4