On Tue, Oct 12, 2010 at 3:46 PM, Tim Bunce <tim.bu...@pobox.com> wrote: > On Tue, Oct 12, 2010 at 03:42:00PM +0200, Leon Timmermans wrote: >> On Mon, Oct 11, 2010 at 12:32 AM, Ben Goldberg <ben-goldb...@hotmail.com> >> wrote: >> > If thread-unsafe subroutines are called, then something like ithreads >> > might be used. >> >> For the love of $DEITY, let's please not repeat ithreads! > > It's worth remembering that ithreads are far superior to the older > 5005threads model, where multiple threads ran with an interpreter. > [Shudder] > > It's also worth remembering that real O/S level threads are needed to > work asynchronously with third-party libraries that would block. > Database client libraries that don't offer async support are an > obvious example.
Hi, I'm showing up only because I happened to check my Perl 6 inbox. For various work related reasons, I'd peeked my head into a couple other language VMs threading implementations. Seems relevant to mention more possibilities: ruby-1.8: - green threads - single actual process - scheduling handled by switching to "something else" after N opcodes are dispatched - system() and other blocking system calls are implemented as non-blocking alternatives - C extensions must also use non-blocking code and be written to call back to the scheduling core - able to share data easily without onerous user-level synchronization because there's really no such thing as being concurrent ruby-1.9 + python: - real threads - global interpreter lock over the core so they're not CPU concurrent - don't have the story for C extensions - able to share data easily without onerous user-level synchronization because there's really no such thing as being concurrent jruby: - Java - real threads - fully concurrent - mostly can't use C extensions - able to share data easily without onerous user-level synchronization because ... ? Java magic? Those implementations all do very well for tasks where actual CPU concurrency isn't needed. A common sweet spot are web services and other things that divide time over IO waiting. They also do well by not having to instantiate separable VMs per thread. They also don't require the user (as in Perl 5) to carefully mark their data as shared because by default everything is shared (but then they don't have actual concurrency either). They do poorly when expected to take advantage of multiple cores. When using this kind of concurrent software for web services, I've compensated by just running enough processes to keep my CPUs busy. I got the advantage of having something that behaved like threads but was extremely easy to work with. This is very unlike my experience with Perl 5 threads which I still fear to work with (mostly because I worry of dangling pointers from difficult to spot miscellaneous magic attachments). Our own threading story could use tricks from the above and include more than just what you've mentioned. Josh