[
https://issues.apache.org/jira/browse/THRIFT-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706259#action_12706259
]
Rush Manbert commented on THRIFT-466:
-------------------------------------
Yeah, that would make sense. The unpatched test has an unfortunate tendency to
hang as well and the patch doesn't change any of that.
I guess there are 2 ways to approach this one. You could run it in a debugger
and step through the new code and see that it does the right thing. That's what
I did.
Or you could apply both patches from THRIFT-487, see that concurrency_test
(mostly) runs, then apply this patch and see that nothing breaks. But you
probably still need to step through it to convince yourself that it's right.
I hate dealing with software sometimes...
> ThreadManagerTests.h blockTest can be more thorough
> ---------------------------------------------------
>
> Key: THRIFT-466
> URL: https://issues.apache.org/jira/browse/THRIFT-466
> Project: Thrift
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 0.1
> Environment: Mac OS X 10.5.6
> Reporter: Rush Manbert
> Attachments: ThreadManagerTestsPatch.txt
>
>
> At the point where the blockTest has created 100 tasks and it tries to add
> one more, but expects to timeout it does not catch
> TooManyPendingTasksException, whici is thrown if there is a bug in the call
> chain represented by canSleep(). In my case, my Boost thread implementation
> had a bug in the getCurrentThreadId() code that caused canSleep() to return
> false, which caused the exception to be thrown.
> There is also no test for attempting to add the extra thread with a negative
> timeout value. In this case, TooManyPendingTasksException should be thrown
> and anything else is a bug.
> I have a patch that modifies the existing try block and adds a second one
> that attempts to add the extra thread with a negative timeout value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
