"Kalaky" <kalaky / gmail.com> schrieb im Newsbeitrag
news:4de0ceaa0411280356785143b7 / mail.gmail.com...
> Do your self a favor and take some time to read:
>
> http://citeseer.ist.psu.edu/schmidt95using.html

Thanks for that link!  I'll read it in the evening.

> And think again about Threaded/Non-blocking I/O.
>
> Keep in mind the "Four Horsemen of Poor Performance":

In the context of our discussion, I'd say there's not too much difference
between the two - considering that we are not talking about a specific
application:

>    1. Data copies

no difference.

>    2. Context switches

These make a difference although OTOH the way continuations are
implemented in Ruby context switches may not differ.

>    3. Memory allocation

The threaded solution needs additional mem for stack etc. but the same
remark as for context switches applies.

>    4. Lock contention

If shared resources are to be accessed safely then you will have no lock
contention with a non threaded solution (i.e. threads waiting for a lock
to become available) but you might have to employ some form of locking
nevertheless to ensure data integrity, resulting in similar behavior.

Lock contention has to be tackled on a higher, more abstract level: you
have to design with concurrency in mind to minimize access to shared
resources and thus lock contention - regardless whether you use threads or
other means to perform concurrent work.  Here's another good source of
information about the matter

http://www.amazon.com/exec/obidos/tg/detail/-/0201310090/

Kind regards

    robert