2015-01-08 14:58 GMT+01:00 Mark Thomas <ma...@apache.org>:
> On 08/01/2015 13:54, Rémy Maucherat wrote:
> > 2015-01-08 14:50 GMT+01:00 Mark Thomas <ma...@apache.org>:
> >
> >>> There's a big deadlock risk if the recursion if incomplete and error
> >>> processing are inside the sync.
> >>
> >> I came across some of those while doing the refactoring. I think - as of
> >> r1650289 - they are addressed but it is possible I missed something. If
> >> you have a particular sequence in mind then I'd be happy to take another
> >> look.
> >>
> > If that new code is also used in upgrade mode, then abusing the drawboard
> > in localhost is a good way to find deadlocks and corruption. But I don't
> > see why these shouldn't be out of the sync block even if it doesn't
> cause a
> > deadlock.
>
> When you say "I don't see why these shouldn't be out of the sync block"
> which code do you have in mind because it isn't clear to me what you mean.
>
>
I quoted it:
public void completed(Integer nBytes, ByteBuffer
attachment) {
- if (nBytes.intValue() < 0) {
- failed(new EOFException(), attachment);
- } else if (attachment.hasRemaining()) {
- getSocket().write(attachment, getTimeout(),
- TimeUnit.MILLISECONDS, attachment,
writeCompletionHandler);
- } else {
- writePending.release();
- if (!Nio2Endpoint.isInline()) {
-
getEndpoint().processSocket(Nio2SocketWrapper.this,
SocketStatus.OPEN_WRITE, false);
I cannot predict any problem, since I see the call to
SocketStatus.OPEN_WRITE was moved out of it using a notify flag, so it
won't deadlock. The error processing uses a dispatch so it won't deadlock
either. Then there's the getSocket().write and I don't know but it could be
fine.
Rémy
