Necessary? I can't see that. It seems patently wrong once you consider the cases that cannot be supported.
On Dec 2, 2017 12:02, "Sven Van Caekenberghe" <s...@stfx.eu> wrote: > > > > On 2 Dec 2017, at 17:21, Peter Uhnák <i.uh...@gmail.com> wrote: > > > > After much digging as to why my tests are timing out even though running > directly was always fine... I found out that TestRunner's coverageRun is > using #valueUnpreemptively to run all tests. > > > > The problem is that one of the tests is retrieving something over > network, and that apparently doesn't go well together. > > > > This works > > > > [ (ZnEasy get: 'http://example.com') entity contents ] value > > > > This freezes the image forever and runs a CPU core at 100% > > > > [ (ZnEasy get: 'http://example.com') entity contents ] > valueUnpreemptively > > > > Is there some resolution to this? > > > > Thanks, > > Peter > > Yes that is weird. > > Just to be 100% clear, it fails with existing websites too. > > [ ZnEasy get: 'http://pharo.org' ] valueUnpreemptively. > > The reason this does not work probably has to do with scheduling. > Socket(Stream)s are non-blocking, they use semaphores internally (in > cooperation with the VM who is probably using something like the select > system call) so that control returns to the image when waiting for IO. > > Note also the comment ! > > BlockClosure>>valueUnpreemptively > "Evaluate the receiver (block), without the possibility of > preemption by higher priority processes. Use this facility VERY sparingly!" > "Think about using Block>>valueUninterruptably first, and think > about using Semaphore>>critical: before that, and think about redesigning > your application even before that! > After you've done all that thinking, go right ahead and use it..." > > The question is, is its use in the coverage tool necessary ? > > Sven > > > > >
