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 > >
