Fast question about threading inside Netty

["Trustin Lee (이희승)"]

It's not impossible to do that with Netty.  Since Netty Channel API is
abstract, you can implement such transport.  I haven't tried it though.
 Since the advantage of such design often fades away as the number of
connections grow, I chose the current design for simpler thread model
and code.

李巍 wrote:
> For one connection, one worker thread do all the io (read, write), my
> question is, since socket is a bidirectional protocol, if using one thread
> for read, another thread for write, will it result in a better response
> time? especially in situation: few connections but more cpu cores.
> 
> On Tue, Mar 23, 2010 at 7:46 PM, Marzullo <coder82 at gmail.com> wrote:
> 
>> You know, I wrote such question after I've read about boss thread and
>> worker
>> thread in case of NIO socket and OIO socket, if you look up the doc, it
>> gives the idea. The point is:
>>
>> OIO socket:
>> Boss thread accepts for connections, when connection is accepted (3 way
>> handshake completed in case of TCP), it creates a channel which represents
>> the accepted connection itself. This channel is handed to a worker thread
>> (often referred as I/O thread) got from thread pool. On such threads, I/O
>> operations are blocking. If you ever implemented a server in C, this is
>> very
>> similar, if not equal to, 1-accepting a socket then 2-create a thread and
>> 3-hand socket descriptor to such thread which will block on reads and
>> writes, that's it.
>> So here the important difference is that you have one accepted channel per
>> I/O thread and every I/O operation within such thread is blocking.
>>
>> NIO socket:
>> Similar to above, boss thread accepts connection, create channel for such
>> connection and hands it to worker thread. The difference is here, you can
>> have more than one channel handed to worker thread, then of course I/O must
>> be non blocking otherwise by blocking on one channel you'd starve the
>> others...
>> So here is the point when I read on the docs:
>>
>> "If await()  is called by an event handler method, which is called by the
>> I/O thread, the I/O operation it is waiting for might never be complete
>> because await()  can block the I/O operation it is waiting for, which is a
>> dead lock. "
>>
>> so if you wait withing such worker thread (I/O thread) you might
>> starve/lower responsiveness on other channels or even cause deadlock
>> depending on what you actually do.
>>
>> It'd be nice to have clarifications from T. Lee about all this.
>> Thanks.
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/Fast-question-about-threading-inside-Netty-tp4765193p4783431.html
>> Sent from the Netty User Group mailing list archive at Nabble.com.
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users

-- 
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: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100324/da6c6592/attachment-0001.bin