Closed: (NETTY-85) Global Channel registry

[Trustin Lee]

I've just checked in the DefaultChannelGroup modification.  It became
somewhat more complicated, but a user shouldn't notice any difference.
The only difference is that close / unbind / disconnect / setReadable
/ setInterestOps operations are performed in a non-blocking manner for
server socket channels as discussed.

Cheers,
Trustin

On Wed, Dec 03, 2008 at 10:48:06AM +0900, Trustin Lee wrote:
> Hi Frederic,
> 
> On Tue, Dec 02, 2008 at 03:36:35PM +0900, Frederic Bregier wrote:
>> Hi Trustin,
>> 
>> Hmm, I didn't think about the asynchronous aspect of the close operation.
>> Thanks for pointing this!
> 
> You're welcome.  Thanks for the feed back!
> 
>> Well, I think you're right with proposing a blocking close request.
>> So I think that users should use at least two groups, one for the
>> parent, and one for the children, and then waiting for the first to
>> be really closed before asking the second to close. That's one option.
>> These options should be explicitely written in the doc. WDYT ?
> 
> Yes, that's your initial suggestion IIUC.
> 
>> Another possibility would be to have the group having two kind of
>> list of channels int it, using the getParent() method.
>> If the getParent() returns null, it is a parent, if not, it is a child.
>> Then when one asked the group to close, it first closes the parent
>> with blocking close, then closes the others channel as usual.
> 
> This one is what I suggested in the previous message.
> 
> <snip/>
> 
>> So that, even if a user makes two groups (one for parent,
>> one for childs), it will block when calling close on the group
>> of parent (awaitUninterruptibly returns immediately).
>> WDYT ?
> 
> Sounds great to me.  Let me modify the current implementation to perform
> as you described.
> 
> Cheers,
> 
 
-- 
Trustin Lee, Principal Software Engineer, JBoss, a division of Red Hat
--
what we call human nature in actuality is human habit
--
http://gleamynode.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/netty-dev/attachments/20081203/4aebe64b/attachment.bin