Uri Guttman wrote: > ...i recommend an event loop server which is stable, faster and > easier to code for in most situations.
Unless POE does a really good job of hiding the details of non-blocking IO, I'd find it hard to believe that an event loop server is easier to code. Once you learn a small bit of threading API, a multi threaded server is conceptually quite simple and most of the code looks as it would for a single threaded, blocking IO application. Ben Tilly writes: >> I don't think an event loop would help, because a computationally slow >> procedure or one that makes a further RPC call would still block other >> clients. > > You can do this with an event loop and multiple processes. > > The RPC server doesn't make RPC calls. Instead it sends a message to > a child process that makes the RPC call. The child process then sends > a message back to the RPC server when it has the answer. The RPC > server can now use a select loop to cycle through getting RPC > requests, forwarding them to children, getting responses, and writing > back to the clients. I'm not sure I see the win in using a mixed model of event loops and multiple processes, aside from avoiding forking/threading inefficiencies at the expense of greater code complexity. Shouldn't it be possible to use non-blocking IO in the main process to talk to other RPC servers, rather than splitting that off to a child process? As for dealing with something "computationally slow," I assume POE and other similar event loop implementations support a mechanism for yielding to the event loop. If so, then as long as your computationally slow chunk of code can be broken up, this too should be doable in the main process. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: https://www.linkedin.com/e/fps/3452158/ _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
