>>>>> "BT" == Ben Tilly <[EMAIL PROTECTED]> writes:
BT> On 10/6/05, Jeremy Muhlich <[EMAIL PROTECTED]> wrote: >> 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. BT> You can do this with an event loop and multiple processes. BT> The RPC server doesn't make RPC calls. Instead it sends a message to BT> a child process that makes the RPC call. The child process then sends BT> a message back to the RPC server when it has the answer. The RPC BT> server can now use a select loop to cycle through getting RPC BT> requests, forwarding them to children, getting responses, and writing BT> back to the clients. you don't even need children to do non-blocking rpc calls. if you do the protocol yourself and it is over a socket (as it should be), you can do async rpc calls. but if you are using a typical library that hardcodes a sync rpc protocol, then you are stuck. this is a major issue i have with most protocol implementations, especially on cpan. they are written with sync i/o and never think about supporting async. what they don't realize is that async can easily emulate sync but it is almost impossible for sync to emulate async. BT> An alternate strategy is to not have a single RPC server. Instead do BT> as Apache's prefork model does, and have multiple processes. Each BT> time you get an RPC call, one process processes the request and other BT> processes remain available to service new requests. preforking is just an optimization of a forking server. if you distribute the processes over a farm of machines, then you can make the main server just connect to the processes on demand or in advance. BT> Unless overhead is a huge concern, I'd personally use the alternate BT> strategy. I'd then avoid writing all of the multi-process logic by BT> using Apache for that piece, and mod_perl to process requests/send BT> responses. and what if you aren't using http for the clients? what if you want to support a cli or a gui client? i really hate how apache (1 or 2) is being touted as the next great application platform and savior. cramming all those different modules (apache and perl) into the insane mess of apache is asking for trouble. anyone ever heard of config file hell? or colliding modules that are too tightly coupled to clean up? but what do i know? just doing event loops for over 20 years on many platforms and in many langs. :) hell, i even integrated c kernel threads into an event loop so i could do blocking ops in the threads and the main code was all event driven. but perl threads just can't cut the mustard like c threads. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
