[Mono-dev] An asynchronous System.Runtime.Remoting.Channels.Tcp

[pablosantosluac at terra.es]

Hi,

Dick and I were talking about the possible race conditions (we've found
one on our code) that the system ThreadPool can have when used from the
channel and the code (remember the *current* tcp channel does not use
the system threadpool but a custom and really simple one).

Would it be possible to use two different thread pools instantiating the
system ones?

Also, would it be possible to commit this code?


Another related idea: it is possible (I think) to greatly improve the
current TcpChannel by returning threads to the pool when they're waiting
at PlasticTcpClientConnection.ProcessMessages.

The problem right now is that each client connection will create a
thread on the server and the thread won't be returned to the pool until
the client closes the connection, even if it's just waiting for data.
This is not good for high-perf environments were many requests must be
processed, since a huge number of threads could be potentially spawned.

My idea would be: we already have a thread for the "socket accept",
create a new one for Socket.Select, so that threads are returned to the
pool (and its socket passed to the Socket.Select call) and then the
method ProcessMessages would be called again when "select" returns. It's
not like a full asynch channel but I think it can be even better on most
situations (less overhead) and it will greatly improve responsiveness.



pablo


www.plasticscm.com


Dick Porter wrote:
> Hi all
> 
> Attached is a patch to add an optional asynchronous path for the TCP
> remoting channel server.
> 
> The main benefit we see with this change is in reliability; when a
> single server is servicing many clients at once (we test with over 100)
> with large data transfers the standard synchronous channel will often
> drop connections.  We tracked this down to the Accept() call in
> TcpServerChannel.cs not being able to get to incoming connections
> quickly enough.
> 
> I was hoping that throughput of large transfers might be improved by
> using the threadpool's asynchronous sockets support, but it turns out
> that performance is pretty much the same as the current implementation.
> 
> Any comments/suggestions for improvement?
> 
> - Dick
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list