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 | gpolo |
|---|---|
| Recipients | georg.brandl, gpolo, loewis, schmir |
| Date | 2008年04月05日.19:31:36 |
| SpamBayes Score | 0.14886953 |
| Marked as misclassified | No |
| Message-id | <1207423897.78.0.339076102781.issue2240@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
I'm investigating the problem loewis, thanks for reporting. But it would be better if someone with running FreeBSD could help me there, in case I find the cause for this. Also some changes were made to the original patch: neal.norwitz did a commit where he says: "Using a negative time causes Linux to treat it as zero, so disable that test." That is not what I get here, maybe a very different kernel, anyway, I believe he could have mentioned this here. jeffrey.yasskin said: ".. fix some flakiness in test_itimer_prof, which could detect that the timer had reached 0 before the signal arrived announcing that fact." followed by these changes: signal.setitimer(self.itimer, 0.2) (old) signal.setitimer(self.itimer, 0.2, 0.2) (new) -> not sure the reason for this change and added: self.assertEquals(signal.getitimer(self.itimer), (0.0, 0.0)) -> this is the same test I did for itimer_virtual, and it is a bit questionable it is really useful at all. I don't understand how these changes matches what he comments on his commit. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年04月05日 19:31:37 | gpolo | set | spambayes_score: 0.14887 -> 0.14886953 recipients: + gpolo, loewis, georg.brandl, schmir |
| 2008年04月05日 19:31:37 | gpolo | set | spambayes_score: 0.14887 -> 0.14887 messageid: <1207423897.78.0.339076102781.issue2240@psf.upfronthosting.co.za> |
| 2008年04月05日 19:31:37 | gpolo | link | issue2240 messages |
| 2008年04月05日 19:31:36 | gpolo | create | |