Here's a great (and recent) comparison of a whole bunch of asynchronous web servers in Python:<br><br><a href="http://nichol.as/asynchronous-servers-in-python">http://nichol.as/asynchronous-servers-in-python</a><br><br>
(via <a href="http://firendfeed.com/amitp">http://firendfeed.com/amitp</a>) <br><br>Steve<br><br><div class="gmail_quote">On Mon, Feb 8, 2010 at 9:04 AM, K. Richard Pixley <span dir="ltr"><<a href="mailto:rich@noir.com">rich@noir.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">My initial experience with either paradigm was coop, (ie, no preemptive scheduling). The entire original macos was cooperative event based. Most windows/icon/mice interfaces, (including X11), were originally event based. And the ISIS toolkit, (an early version of what is now called "virtual synchrony"), was a messaging system without a "read" call. Instead, incoming messages spawned a "thread", (really implemented as a coop event based tasking system).<br>
<br>
Also, my first asynchronous parallel system was back in the 80's with Sequent Balances and later Symmetries combined with Sun 3/50's. There were no widely available threading systems then although the coop threading systems were beginning to show up in various places. I designed and built an entire multiple machine, asynchronous ticker plant using heavy weight unix processes, sysv unix IPC, sockets, and hardware atomic locks. (And later replaced it with an ISIS based system).<br>
<br>
Early implementations of threads were cooperative and many were implemented using event based systems. That is, threads which blocked blocked the entire heavy weight process. At that point, the distinction between threads and an event based system was largely moot. If you wanted an asynchronous system, then you had to think about blocking and potential task switching with each and every call either way.<br>
<br>
Granted, modern threading systems are preemptive and much more heavy weight than the earlier systems. Threads have lost much of their efficiency in favor of a simplified user paradigm, (aside from debugging), which now virtually mimics the original unix process paradigm, (complete with shared memory, forks, multiple asynchronous processes, atomic hardware locking, etc). Personally, I'd prefer to use the unix facilities at that point because they are more efficient and easier to debug. From that perspective, threads offer very little in the way of functionality or efficiency over prior, well known alternatives.<br>
<br>
I agree that if you haven't used any of these paradigms, then threads might be a simpler paradigm to learn initially, if you assume that your threading system is part of your operating system or you assume that all threading systems are preemptive and therefor comparable. Event based systems force the developer to confront the task switching mechanism and to sort through starvation scenarios. If you're going to sort through those scenarios anyway, or if you're going to need to examine your switching mechanism closely, then I argue that event based systems are simpler to understand in total than thread based.<br>
<br>
So I suppose I agree that if you only need to understand a portion of the problem space, then threads are probably easier, (so long as you don't need to debug anything).<br>
<br>
--rich<div><div></div><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
Baypiggies mailing list<br>
<a href="mailto:Baypiggies@python.org" target="_blank">Baypiggies@python.org</a><br>
To change your subscription options or unsubscribe:<br>
<a href="http://mail.python.org/mailman/listinfo/baypiggies" target="_blank">http://mail.python.org/mailman/listinfo/baypiggies</a><br>
</div></div></blockquote></div><br>