>>>>> "BT" == Ben Tilly <[EMAIL PROTECTED]> writes:
>> 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> I assumed that he wouldn't want to rewrite things like database BT> drivers, so I was assuming that he'd be stuck. After all, if he was BT> using async protocols, then he'd have never complained about blocking BT> calls. true about dbi and other sync modules. but i won't assume anything since the OP has not given a full problem spec (yet). >> 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> The key feature that I was pointing to was having multiple BT> processes, not the pre-forking optimization. I specified prefork BT> to distinguish it from the threading model that Apache 2 also BT> offers. i also like the process farm idea and have used it many times. 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. but what if you already had a tool in perl that let you do all the async communications with no new coding needed? and it can do application servers as well? :) >> 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? BT> If you're building the system from scratch, you can use any protocol BT> that you want for the clients. It doesn't matter what kind of clients BT> you have. sure. again we have no proper spec so i won't speculate. BT> As for your complaints about config file hell, there are plenty of BT> known techniques to keep complex Apache applications cleanly BT> organized. If you are going to have 50 million applications in the BT> same Apache process, then you have a problem. But if you're talking a BT> single application which you're considering devoting multiple machines BT> to, then the necessary overhead to set up Apache for your needs is BT> less than the overhead to roll your own application server, or to BT> write event loops for everything. that still doesn't mean using apache and http for app serving is a good idea. http is stateless so it makes for a bad protocol for when you need multiple remote operations on a single session. sure you can work around it (cookies) but that is still a workaround. BT> Before you disagree with the last, note that I'm counting as overhead BT> having to implement asynchronous wheels because you don't like the BT> blocking that happens with the synchronous one on CPAN... hmm, what if the wheels are there and rounder than the square ones you currently have? >> 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. BT> And this makes anything that I've said any less true? no, but it shows that threads and events can work together if needed. BT> Note that I'm not saying that Apache is a perfect strategy. I'm BT> not saying that it has no drawbacks. I'm just saying that it is a BT> workable strategy in many situations, and it is the strategy that BT> I'd be inclined to use fairly often. i would vote against it. too many apps require sessions so it loses there with http. http also has to incur much overhead to transfer binary data. BT> If you want perfection, then it is clearly the wrong way to go. But BT> the perfect is the enemy of the good, and it is a pretty good BT> solution. and a bad solution hurts forever. :) i have too much experience with event loops and code to back me to start going in the direction of apache as an app server. in fact my view is to use apache as a *front end* but it does little other than to handle http and static requests. all cgi stuff is packed up and sent to a middleware layer which does all the work. you get real normal perl (mod_perl also is slightly nutso compared to regular perl) and a simple faster apache. and the middleware layer can be on other boxes, it can do async backend stuff, parallel ops, etc. then apache is just a simple UI, no different to the middleware than a cli with a socket or anything else. 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
