valueUnpreemptively breaks coverage with ZnClient

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

valueUnpreemptively breaks coverage with ZnClient

Peter Uhnák
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
Reply | Threaded
Open this post in threaded view
|

Re: valueUnpreemptively breaks coverage with ZnClient

Sven Van Caekenberghe-2


> On 2 Dec 2017, at 17:21, Peter Uhnák <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: valueUnpreemptively breaks coverage with ZnClient

Richard Sargent
Administrator
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" <[hidden email]> wrote:


> On 2 Dec 2017, at 17:21, Peter Uhnák <[hidden email]> 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