Okay, done. On Fri, 2009-03-27 at 19:21 +0200, Alin Dreghiciu wrote: > Yep, just commit. > > On Fri, Mar 27, 2009 at 6:57 PM, Sebastien Braun <[email protected]> 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 > > [email protected] > > http://lists.ops4j.org/mailman/listinfo/general > > > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
