Hello, On Fri, 2009-03-27 at 15:46 +0200, Alin Dreghiciu wrote: > But I never encountered your situation. It may be good if you upload > the code somewhere so I can test/debug. Maybe your own laboratory at > ops4j?
I think I nailed the cause of the problem. To generate the problem, you need a pipe, via the ThreadIO streams, with a producer that generates data faster than the consumer can read it from the PipedInputStream. Since the println(..) methods of PrintStream obtain the Monitor, and ThreadPrintStream inherits them unchanged, any call to println(..) will lock the Monitor on the *shared* ThreadPrintStream. When the data producer calls println(..), and the PipedInputStream has no free space, it will block, with the lock on the shared ThreadPrintStream still held. The consumer then tries to generate output via System.out.println(..), which tries to lock the shared ThreadPrintStream, and ... deadlock. The solution seems to be to replace all monitor-entering methods on ThreadPrintStream by methods that delegate to getCurrent(). I have a patch that does exactly that. Should I commit it? Cheers, Sébastien P.S.: In case you are interested, the code for my command adapter is located at https://scm.ops4j.org/repos/ops4j/laboratory/users/brs/shelladapter _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
