Newbee question here.

[Alex Martelli]

"Patio87" <patio87 at aol.com> wrote in message
news:20010812030438.00855.00003992 at ng-cl1.aol.com...
> Thank you alot for your feedback on my question, but I dont really
understand
> mouch of what you aid. Can you say that in stupid languge so i will
understand.
> Im very new to python and programming its self. I have had python for
about two
> days and have all ready read a whole tutorial but if you could repeat what
you
> said in a much easier way I would MUCH apreciate it Thanks

Let's try.  Your original question was, "what exactly does medusa do".  Both
Dave
and Peter Hansen answered well, but if you're very new to programming, you
may need more background in the answer.  So, let's start from way back...

A computer normally does only one thing at a time: it has a "Central
Processing
Unit" (CPU), e.g. an AMD Athlon or Intel Pentium or whatever, that processes
one instruction after the other.  This isn't strictly and literally true
nowadays,
since modern CPUs have a modest degree of "parallelism", some computers
have several CPUs (so-called "multiprocessor" machines), and other smart
chips
that are part of your computer may be doing specialized work while the CPU
is
busy doing something else -- but it's a good first approximation, so let's
take
it as a starting point.

However, we very much want the *appearance* of a computer doing many
things at the same time.  This is mostly the operating system's (OS) job,
and it's
often called "multitasking".  The OS switches between several programs (or
to be more precise, several _processes_) very fast, thus giving the
appearance
that the programs are working in parallel.  The interesting problem,
however,
is when we want just ONE program, that we write, to (appear to) do many
things at once.

Why would we want that?  For several reasons, but, in the context of medusa,
the key reason is getting better overall performance.  Suppose that the task
of our program is sending requests to many servers over the internet: for
each request that is sent, a server will (eventually) send a response, and
our
program must collect the responses and do something with them.

Now, the internet is SLOW in computer terms.  Once a request is sent, it
must take a long trip, gets queued at the server, and eventually the server
gets around to it, prepares the response, and sends it back -- the response
again does the long trip, in reverse.  The delays are technically called the
*latency* of the communication.  They may easily amount to something
very substantial, say one second.  That's a million microseconds, time
enough
for a modern CPU to execute many millions of instructions.  The natural
approach, where each request is sent, then the sender waits until the
response comes back, then the next request is sent, and so on, is a very
serious waste of time -- if we need to send a thousand requests, even the
fastest computer will take 1000 seconds, over a quarter of an hour, if
each latency is of 1 second.

Human parallel: say you want to send a postcard to each of 20 friends and
wait for answering postcards.  Each postcard-round-trip may have a
latency of, say, one week.  If you send one postcard at a time, and wait
for the answer before sending the card to the next friend, you won't be
done for almost five months!  So, what's the solution...?

The solution to the human-parallel problem is pretty clear I hope: you
send all the postcards WITHOUT waiting for answering postcards.  In
a hour or so you're done, THEN you wait (for about a week) and the
answers start to come in.  In a bit more than a week, rather than many
months, the whole task will be done.

And the parallel extends to the computer problem: your program can
send the requests one after the other without waiting for the answers,
THEN wait if need be until all the answers have come in.  That may
take a few seconds for 1000 requests, rather than many minutes.

The problem is how to coordinate the several tasks that the computer
(specifically, the one program you're writing) must be performing "at
once" to make this happen.  In general you can't really send everything
first -- some server may answer fast enough, that the response arrives
while you're still sending other requests, and your program needs to
receive that response and act on it before continuing to send the other
requests.  Moreover, most internet interactions aren't quite as simple
as one-request/one-response, but involve a 'chat' (dialogue, protocol)
where quite a few request/response pairs happen -- this, too, needs
precise coordination.

There are several ways to tackle this, and medusa is one of these ways --
an insanely great and brilliant one, incidentally, with an overall
performance and such a light load on your computer that they must
really be seen to be believed.  It achieves that much by adopting a
very simple model, and your program must adapt to that model, but
it's DEFINITELY worth the effort.  Actually, medusa is oriented to your
program being the server, rather than the client interacting with
multiple servers (although you may use it for that).

Now, if this is all clear to you up to here, we may perhaps get into
more depth about what distinguishes medusa from other approaches
and how you must structure your code to exploit medusa's strengths.

But that's basically what Dave was saying, and pretty well too, though
his answer DID presumably assume you well knew all I've been
trying to explain here (and quite a bit more besides, such as, what
is 'asynchronous' I/O, what is multi-threading, and so on).  Still, if
you're clear with the issues up to this point, and still interested, the
rest is going to be easy to explain, so, let us know!


Alex