valueUnpreemptively breaks coverage with ZnClient
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
On 2 Dec 2017, at 17:21, Peter Uhnák <i.uhnak@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
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" <sven@stfx.eu> wrote:
On 2 Dec 2017, at 17:21, Peter Uhnák <i.uhnak@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
participants (3)
-
Peter Uhnák -
Richard Sargent -
Sven Van Caekenberghe