"can NOT check"*, in the first sentence.
> On Jan 12, 2016, at 11:05 AM, Skip Lentz <skip.le...@inria.fr> wrote:
>
> You mean as in it can check the coverage effected by the code running in the
> other thread?
> Or is this not what you mean?
>
> Well I mean, at least it can show the coverage done by what was run in the
> same thread..
> And it will at least not hang or fail.
>
>> On Jan 12, 2016, at 10:59 AM, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>>
>> I never used that, but it seems coverage can only deal with single threaded
>> code, which sounds logical. No ?
>>
>>> On 12 Jan 2016, at 10:53, Skip Lentz <skip.le...@inria.fr> wrote:
>>>
>>> Hi,
>>>
>>> When I want to run the coverage of for example Zinc’s Client and Server
>>> tests,
>>> it will either hang (in the case of Zinc’s test cases) or fail because the
>>> coverage
>>> uses BlockClosure>>valueUnpreemptively for running the tests.
>>> The relevant method is TestRunner>>collectCoverageFor:.
>>>
>>> So when a test is run, it is not able to be preempted by another process,
>>> like for
>>> example a local server which is needed to run the actual test in Zinc’s
>>> case.
>>>
>>> When I use BlockClosure>>valueUninterruptably it works. Can someone tell me
>>> if it is wrong to use that instead? Is valueUnpreemptively necessary in
>>> this case,
>>> and if so, why?
>>>
>>> To reproduce: Load fresh image, select Zinc's ZnClientTests and
>>> ZnServerTests,
>>> click on “Run Coverage” -> hanging image.
>>>
>>> Thanks,
>>>
>>> Skip
>>
>>
>
