The talk I gave was about threading models in general in scripting languages.
Threads are defined by a shared address space, so ithreads are not threads in the first place. Many people (including you) confuse them with real threads (as implemented by Coro), doubtlessly because of the badly chosen name.
What I wanted to show, and without doubt succeeded, is that in data-sharing-extensive scenarious, ithreads totally lose, because they can't share data efficiently (which is normally the only advantage of threads).
I also showed that data sharing is so slow with ithreads as to be useless. real processes certainly perform better than ithreads in about any scenario.
the problem with ithreads is that they emulate unix processes (thats what they were written for), in software, something a unix system does efficiently in hardware.
This cpu/mmu emulation costs around 25%, whether used or not. It also means that unlike unix processes, starting a pseudo ithreads process involves a very costly copy operation, doubling the amount of memory used (under unix only small amounts of memory are neecsssary).
So, the bad points about ithreads is that they slow down every perl interpreter for a windows hack, that they slowly emulate in software what on a typical OS today does in hardware, and that it doesn't implement threads at all, as it emulates processes. Processes, of course, can be had faster and with much less overhead by, well, using OS processes instead of the emulated ones.
What's in favour of ithreads? The only thing is the existing API that allows yout o create and join processes easily, and implements data copying between them. That advantage is, however, no longer existing now that theAPI-comaptible "forks" module exists, which implements the ithreads API using real processes, outperforming it greatly in most cases.
So in summary, ithreads are a total misnomer, as they don't even implement threads. They should not be enabled on non-windows perls for that reason, as non-windows perls have a hardware-assited process implementation, which cna be used instead.
The benchmark is meant to illustrate how expensive it is to treat ithreads as if they were real threads (both in program complexity as well as in cpu time), compared to a real threads package.
Without doubt, it did succeed in that.
In reply to Re^12: If I am tied to a db and I join a thread, program chrashes
by Anonymous Monk
in thread If I am tied to a db and I join a thread, program chrashes
by lance0r
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |