Yep, just commit. On Fri, Mar 27, 2009 at 6:57 PM, Sebastien Braun <b...@yellowhippy.com> wrote: > 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 > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general >
-- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. Looking for a job. _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
