On 12 Oct 2010, at 16:29, [email protected] wrote: > "Levente Uzonyi"<[email protected]> wrote: >> Okay, I really tracked down the cause of the problem. The tests perform >> simple producer-consumer scenarios, but the consumers won't wait at all. >> If there's nothing to consume, the test fails. The randomness come from >> the scheduler. The server process is started first, the client is the >> second. If the server process can produce enough input to the client >> process the test will pass. >> If you decrease the priority of the client process by one in >> #timeout:server:client:, the randomness will be gone and the tests will >> reliably pass, because the client won't be able to starve the server. To >> avoid false timeouts I had to increase the timeout value to 2000 >> milliseconds using SqueakVM. > > An alternative solution I was thinking about would be to dispense with the > processes in default case and simply run the server and client blocks > sequentially. The cases where we really need the processes are channels with > limited capacity (e.g. Socket or Pipe) where the writer needs to be able to > block (when the OS buffers fill up) and let the reader consume some of the > output before it continues writing. In these cases there aren't any shared > resources so process contention should not be an issue. The other advantage > would be that cases with the default behavior would be easier to debug and > would not be subject to timeouts. As it is I still get timeouts sporadically > even when it's set to 1 second.
Yes, having strangely behaving unit tests is really annoying, especially when all this process stuff would not really be needed. >> I also found an issue: the process in XTTransformWriteStream doesn't >> terminate. If you run the tests, you'll get 12 lingering processes. > > I don't see that happening in Pharo 1.1. Normally the process should end > normally when the stream is closed (the close synchronizes with the process > via the closeReady semaphore). Maybe there's a missing close somewhere in the > test suite ? I have these hanging processes as well (you probably know that the Process Browser does not auto update by default ?), I've never seen unit tests that did that... > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
