On 10/6/05, Uri Guttman <[EMAIL PROTECTED]> wrote: > >>>>> "BT" == Ben Tilly <[EMAIL PROTECTED]> writes: > > BT> On 10/6/05, Jeremy Muhlich <[EMAIL PROTECTED]> wrote: [...] > 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.
I assumed that he wouldn't want to rewrite things like database drivers, so I was assuming that he'd be stuck. After all, if he was using async protocols, then he'd have never complained about blocking calls. > 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. The key feature that I was pointing to was having multiple processes, not the pre-forking optimization. I specified prefork to distinguish it from the threading model that Apache 2 also offers. > 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? If you're building the system from scratch, you can use any protocol that you want for the clients. It doesn't matter what kind of clients you have. For instance I am using Ubuntu at the moment. It uses an http interface to fetch package information and packages when you want to upgrade. But this http interface is not accessed through a browser. Instead you can access it through the purse CLI interface of apt, through the curses interface of aptitude, or through the GUI interface of the Synaptic Package Manager. The protocol spoken over the wire is separate from the front end. As for your complaints about config file hell, there are plenty of known techniques to keep complex Apache applications cleanly organized. If you are going to have 50 million applications in the same Apache process, then you have a problem. But if you're talking a single application which you're considering devoting multiple machines to, then the necessary overhead to set up Apache for your needs is less than the overhead to roll your own application server, or to write event loops for everything. Before you disagree with the last, note that I'm counting as overhead having to implement asynchronous wheels because you don't like the blocking that happens with the synchronous one on CPAN... > 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. And this makes anything that I've said any less true? Note that I'm not saying that Apache is a perfect strategy. I'm not saying that it has no drawbacks. I'm just saying that it is a workable strategy in many situations, and it is the strategy that I'd be inclined to use fairly often. If you want perfection, then it is clearly the wrong way to go. But the perfect is the enemy of the good, and it is a pretty good solution. Cheers, Ben _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
