Why channel.write blocked if I block messageReceived on same channel?

["이희승 (Trustin Lee)"]

On 08/20/2010 01:45 AM, tsuna wrote:
> On Thu, Aug 19, 2010 at 9:15 AM, man4j <man4j at ya.ru> wrote:
>> 1. If I block in method messageReceived (f.e. Thread.sleep or breakpoint)
>> then channel.write(in separate thread) only put data in queue, but not send
>> via socket until messageReceived still blocked. Why?
> 
> I *think* it's because when you call channel.write() it will attempt
> to send a message downstream through the channel's ChannelPipeline.
> But the ChannelPipeline is already "busy" in messageRecevied.  And a
> ChannelPipeline is only active in one thread at a time (by default).
> So Netty has to wait until messageReceived gets unblocked and
> completes before it can process the downstream message you wrote with
> channel.write().
> Normally you're not supposed to block in messageReceived.

Strictly speaking, it is not correct.  ChannelPipeline does not block
events from being processed simultaneously.  A Channel is assigned to an
I/O worker thread.  Once assigned, it is never reassigned to other I/O
worker thread.  Therefore, all read/writes occur in the same thread.  If
you perform a blocking operation in your handler, the I/O worker thread
will be blocked - they are the same thread.  Therefore, write will not
be performed until the handler returns the control to the I/O worker.

>> 2. channel.write is thread-safe?
> 
> Yes.

Thanks for answering the question.  Please feel free to post your
opinion, answers, whatnot to help the whole community can brainstorm how
to improve Netty! :)

Cheers,
Trustin
-- 
what we call human nature in actuality is human habit
http://gleamynode.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 293 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100826/d60bc0e3/attachment.bin