Thread pooling in AIO?

[Nord, James]

> On 12/16/2008 11:48 AM, Nord, James wrote:
> > The other thing is the default is awfull in our tests - as 
> it seems to 
> > create a new Thread in the pool for each AsyncDatagramChannel  (for 
> > 100 multicasts received there were 130+ java threads).
> 
> That's the way that fixed thread pools work.  The core size 
> is equal to the pool size.  

Do you not mean a cached pool?

>If ThreadPoolExecutor.execute() 
> is called and the number of threads is below the core size, 
> then a new thread is created rather than reusing an old one.  
> I think a fixed pool is probably the wrong choice for async 
> I/O - it would make more sense to use a cached pool which can 
> scale up on demand, with a sensible timeout for non-core threads.

Whilst hundreds of threads may work well on NagraII boxes most intels
have 8/16 or so cores you just end up in context swapping and
contentending for resources which hurts.

> One must also consider the task rejection policy - I don't 
> think it would be a good thing for async I/O tasks to be 
> rejected since the caller would have no idea what happened to 
> the operation.  It would just "disappear".

Is it rejected or does it block?  I would say it should block.  If this
ends up down the line of having packet loss then that's in my opinion
fair game.

But what is the relationship between the native AIO layer and the
threads we have here?
At the native layer any thread can call GetQueuedCompletionStatus on the
same IOCompletionPort...
Are the threads we supply going to be in GetQueuedCompletionStatus until
we have some data at which point they pop back into java land and invoke
the CompletionHandler?

In which case tasks should not be rejected - and the only possibility is
we can not handle the data fast enough.  But with one thread per cpu
core we could not really run any faster if we tried.

/James

*********************************************************************************************************
This e-mail is confidential, the property of NDS Ltd and intended for the addressee only.  Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited.  If you have received this message in error, please immediately notify the postmaster at nds.com and destroy the original message.  Messages sent to and from NDS may be monitored.  NDS cannot guarantee any message delivery method is secure or error-free.  Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.  We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission.  You should carry out your own virus checks before opening any attachment.  Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS.

To protect the environment please do not print this e-mail unless necessary.

NDS Limited Registered office: One Heathrow Boulevard, 286 Bath Road, West Drayton, Middlesex, UB7 0DQ, United Kingdom. A company registered in England and Wales  Registered no. 3080780   VAT no. GB 603 8808 40-00
**********************************************************************************************************