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
My suggestion would be using a separate ThreadPool for the channel than
the one used by the system, since Dick is aware race conditions can
happen (deadlocks) between code using the System ThreadPool in the
process and the channel.
Diff. ThreadPools will fix it.
pablo
Miguel de Icaza
Hello,
I like this patch very much, and I like that the way to enable it is
through the new run_async configuration option.
My only feedback is that I believe this is a nice enough feature
that it deserves at least:
* A blog entry announcing it, linking to:
* A page on
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
