>>>>> "BT" == Ben Tilly <[EMAIL PROTECTED]> writes:
BT> I already indicated reasons to pick a design where synchronous calls BT> are not an issue. An additional reason to avoid cooperative BT> multitasking is scaleability - multiple processes allow you to benefit BT> from multiple CPUs (both real and virtual), and make the migration to BT> multiple machines easier. A cooperatively multitasked program can BT> only use one CPU. (But cooperative benefits from being able to BT> communicate between tasks very directly. However if you do too much BT> of that, it is easy to accidentally introduce race conditions. BT> Particularly if you try to be asynchronous everywhere.) you can run multiple event loop processes (some would be children that do blocking ops) on a multiprocessor and gain all the speedup. you can easily avoid race conditions. actually in a classic event loop, you can't have them as only one logical thread is ever executing at one time. so you don't need locks or semaphores. while race conditions can be avoided, deadlock is another issue but that is an issue no matter the logic flow paradigm unless you have transactions or similar things. BT> My point remains. Wanting to support a CLI or GUI client does not BT> prevent you from using http. Your suggesting that it does is a red BT> herring. no, i am not. you can do anything with any transport (call them turing compatible! :). how easy it is becomes the question. using cookies to overcome the lack of state in http is just not right. sure it can work but it has all sorts of fun problems as we have all seen. if you follow your logic to its conclusion, we should all use just http for all the net (the intarweb rules!). i am saying too much is overloading http and it is fugly. soap, xmlrpc, torrent (hell, it invented its own simple protocol and still uses http for something it could do itself. poor design forces a torrent system to also have a web server built into it) all (ab)use http. 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... i have a germ of an article that will show (hopefully with a working example) of how to convert a typical sync cpan protocol module to async. some will convert easier than others though. BT> What rounder wheel than DBI do you have to offer me? not a dbi wheel but the rest of the wheels. and even a dbi wrapper in a nice round wheel. :) BT> [...] 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> Did I say they couldn't? no, but i wanted to show they are not total enemies. BT> True. See my above comment about how allowing for the use of BT> synchronous pieces is a piece of future-proofing. :-P where did i say you can't support sync stuff? (same kinda question you are tossing at me). i just said async is better than sync (if you can do it) and you can wrap sync in child processes and thereby make them async (the parent process is still async). BT> As for your exact solution, if it works for you, it works. However BT> the benefits that you're getting seem fairly marginal to me. BT> Furthermore if you want high performance in a web environment, both BT> reason and experience (my own and that of many others that I know) BT> says that middleware servers don't really help scaleability. and others say otherwise. :) BT> Yes, I know that vendors swear the opposite about middleware up and BT> down until their faces turn blue. But those same vendors have a BT> vested interest in seeing you buy *more* machines, not less. And, as BT> I say, the examples that I'm personally aware of contradict what BT> vendors try to tell you. most of those are commercial close source bloatware middleware layers. not even close to what i am talking about. but we will agree to disagree. 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 Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
