[Baypiggies] asynch design

[Stephen Lacy]

Here's a great (and recent) comparison of a whole bunch of asynchronous web
servers in Python:

http://nichol.as/asynchronous-servers-in-python

(via http://firendfeed.com/amitp)

Steve

On Mon, Feb 8, 2010 at 9:04 AM, K. Richard Pixley <rich at noir.com> wrote:

> 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).
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
> 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).
>
> --rich
>
>
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20100208/5426bc5c/attachment.htm>