On 10/6/05, Jeremy Muhlich <[EMAIL PROTECTED]> wrote: > On Thu, 2005-10-06 at 18:36 -0400, Uri Guttman wrote: > > even the people who wrote the threads code in perl disavow them, so i > > wouldn't even try to do any heavy threading in perl. instead i recommend > > an event loop server which is stable, faster and easier to code for in > > most situations. you can use stem, poe, event.pm or even io::select as > > the main event loop. > > The problem is that I'm writing an RPC server that itself needs to make > RPC calls. I can't be blocking on new clients connecting or existing > clients sending requests while the server-side procedure is making its > own RPC call out to somewhere else. > > 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. This is conceptually similar to what you might do with a multi-threaded server - you're just using processes rather than threads. An alternate strategy is to not have a single RPC server. Instead do as Apache's prefork model does, and have multiple processes. Each time you get an RPC call, one process processes the request and other processes remain available to service new requests. Unless overhead is a huge concern, I'd personally use the alternate strategy. I'd then avoid writing all of the multi-process logic by using Apache for that piece, and mod_perl to process requests/send responses. Cheers, Ben _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
