ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Next set of JavaDoc patches
Date Mon, 18 Feb 2002 20:35:58 GMT
I have a two cpu setup at work for better thread testing (only 700M cores
backed by only 512MB of rdram , but they replicate server configs fairly
realistically). I could try running the test case there. MP systems are much
better at finding threading bugs, in your own and sadly other peoples code.
Example: since I added the #2 CPU, the CD-R drive causes bluescreens
whenever I try to burn in it.

Sam: does the GUMP run in a single or multi CPU system?

----- Original Message -----
From: "Jon Skeet" <>
To: "Ant Developers List" <>
Sent: Monday, February 18, 2002 11:20 AM
Subject: RE: Next set of JavaDoc patches

> >Identified thread-safety problem in DemuxOutputStream (look for XXX)
> Interesting,. There is a bug entry about odd output running <java> in
> <parallel>, but like most thread problems, replication is a
> dog. maybe this was the cause.

I'd be thrilled if what I was doing turned out to be immediately useful :)

Just for my own reference if I decide to go back and track this:

Reproducing this could be interesting, certainly - you need to *happen* to
get a thread context switch between write ('\r') and write ('\n') in one
thread *and* the other thread get both '\r' and '\n' before the other thread
gets in again. On the other hand, putting some kind of logging (and
conditional sleeping, possibly) in the potentially problematic bit of code
could make it more easily reproducible.

I can't actually see why we'd get this behaviour though - I would have
thought the streams would get processed eventually when they were


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message