Le Tue, 16 Feb 2010 01:50:59 +0100,
Emmanuel Lecharny <[email protected]> a écrit :

> Hi,
> 
> some random thoughts about server initialization. The way a server is 
> initialized is by bind the addresses we want the server to listen on
> on an IoAcceptor. Note that this initialization is done in three
> steps :
> - a first step is to bind the address. A future is created, put in a 
> queue (registerQueue), and the acceptor is started, which do a
> select() with not timeout, and the selector is woke up. This is it
> for the first step, for the moment, as we are waiting on the future
> to be done.
> - the second step quicks in when the selector is woke up. The 
> registerHandles() method is called, it pull the futures from the 
> registerQueue(), then for each of them, it opens a
> ServerSocketChannel and initializes it. A the end, the channel is
> registered on the selector with an OP_ACCEPT flag, and inform the
> future that it's done. The thread now coninue processing incoming
> connection handles, and unbind requests (unlikely to have any ...),
> and at the end, block on the select() waiting for bind(), unbind() or
> connect events.
> - The third steps consists on firing all the attached listeners, one
> of them is the statisctic listener.
> 
> And that's it. I tried to be dense here, but trust me, you need
> aspirin power 2 to get a clue about what all this does.
> 
> Now, some ideas about MINA 3/0:
> - first, in the three described steps, you can be sure that the third
> oe is not done properly, as the listeners may perfectly well be
> executed *after* the server has started received some new connection
> requests, and eventually executed some processing on them, f*cking up
> the stats. This is bloody wrong, but, meh, this is just about stats,
> so who cares ???
> - second, I'm not sure we want to bind a new address once the server
> is started. There may be some use cases, but in any case, I would not
> let the Acceptor thread dealing with bind operation
> - third, and this is the major point, why do we have to use a future,
> a queue, some complex synchronization between two threads when all
> this can be done in one single thread : we can perfectly create and
> configure the new ServerSocketChannel *before* registering it on the
> selector, up to the point all the listeners and data structures have
> been processed. Then, and only then, we attach the channel to the
> selector.
> 
> Really I think MINA 2.0 is way to complex. Simple things should
> remain simple...
> 
> The unbind operation should also be handled in a simple way : it's
> just a matter of unregistering the channel from the selector, then to
> handle the cleanup...
> 
> Did I missed something ?
> 

When you want to register a socket to a Selector and another thread is
calling select(); the register operation will block until select();
exit. I think that's why a queue is used.

-- 
Julien Vermillard

Archean Technologies
http://www.archean.fr

Attachment: signature.asc
Description: PGP signature

Reply via email to