From: "Klaas-Jan Stol" <[EMAIL PROTECTED]>
Date: Wed, 2 Jan 2008 16:16:26 +0100
what about "joining" threads, and comparing the output at those points? For
async IO, a join is more or less implemented by a "wait" operation, no? (or
the parrot equivalent for that).
just a thought
what about "joining" threads, and comparing the output at those points? For
async IO, a join is more or less implemented by a "wait" operation, no? (or
the parrot equivalent for that).
just a thought.
kjs
On Dec 31, 2007 8:57 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Monday 31 December 2007
On Dec 31, 2007, at 11:57 AM, chromatic wrote:
On Monday 31 December 2007 05:50:47 Allison Randal wrote:
In the concurrency work I'm about to check in, I have some tests that
fail intermittently because they test for something like:
1
alarm1
2
alarm2
3
alarm3
alarm1
alarm3
4
alarm3
alarm3
ala
> In the concurrency work I'm about to check in, I have some tests that
> fail intermittently because they test for something like:
>
> But, as we add more asynchronous code, and more asynchronous tests, we'll
> need to do more thinking on our strategies for testing a
chromatic schreef:
On Monday 31 December 2007 05:50:47 Allison Randal wrote:
In the concurrency work I'm about to check in, I have some tests that
fail intermittently because they test for something like:
1
alarm1
2
alarm2
3
alarm3
alarm1
alarm3
4
alarm3
alarm3
alarm3
5
done.
When the actual
On Monday 31 December 2007 05:50:47 Allison Randal wrote:
> In the concurrency work I'm about to check in, I have some tests that
> fail intermittently because they test for something like:
>
> 1
> alarm1
> 2
> alarm2
> 3
> alarm3
> alarm1
> alarm3
> 4
> alarm3
> alarm3
> alarm3
> 5
> done.
>
> Wh
27;s to force some
order on the results, and I'm changing them to "like" tests instead of
exact matches with a few modifications to the output. But, as we add
more asynchronous code, and more asynchronous tests, we'll need to do
more thinking on our strategies for testing asynchronous code.
Allison
