This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
| Author | pitrou |
|---|---|
| Recipients | nnorwitz, pitrou |
| Date | 2008年03月27日.16:22:38 |
| SpamBayes Score | 0.081930004 |
| Marked as misclassified | No |
| Message-id | <1206634960.5.0.607743048032.issue2496@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Hmm, I think I know what happens. t_bootstrap() in threadmodule.c calls the self.__bootstrap() method in the Thread object, and it is this method which sets the __stopped flag at its end, which in turns wakes up the join() method. The problem is that at this point, t_bootstrap() still (rightly) holds a reference to the Thread object, since it has a reference to its __bootstrap() method which is still running. Depending on how the operating system switches threads, this reference may or may not be released when the join() method returns. So I think it's the test that is flaky. Instead of calling the join() method, it should wait for the OS-level thread to finish. Or it should find another way of testing for the reference cycle. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年03月27日 16:22:40 | pitrou | set | spambayes_score: 0.08193 -> 0.081930004 recipients: + pitrou, nnorwitz |
| 2008年03月27日 16:22:40 | pitrou | set | spambayes_score: 0.08193 -> 0.08193 messageid: <1206634960.5.0.607743048032.issue2496@psf.upfronthosting.co.za> |
| 2008年03月27日 16:22:39 | pitrou | link | issue2496 messages |
| 2008年03月27日 16:22:38 | pitrou | create | |