>From Jim Bodwin: > Note that this worked just fine with the old 5.005 threads (which > shared everything). I understand that they have ripped the old 5.005 > threads out starting with 5.10 but you can still use 5.005 threads with > current versions of Perl. We (GreenLight) have been using 5.005 threads > in production code for years and it works great (although we did NOT use > locks - we count on scheduling).
I believe I've heard from at least one other company using 5.005 threads in production. I've also heard from any number of people who claim that they bomb all the time. C'est la guerre. I personally feel that the move from 5.005 threads to ithreads is a step in the wrong direction. Don't get me wrong, as a Windows user I get as much benefit from ithreads as anyone. I always figured ithreads were started as a way to dummy up fork() on Windows. But that's the problem. When I call for a "thread" I don't want the threading model to resemble fork(). I want a separate flow of control in the same program/data space. I don't mind if I have to roll my own locks, monitors, and so forth to protect my data. That's what I get paid to do (when I get paid ;). Which is, as I understand it, the big argument for ithreads. No one wants to muck up performance for non-threading users by wrapping locks around all of the Perl internals. And since we're dealing with an interpreter, not compiled code, it's easy to believe that this would be required at a very low and pervasive level in order to work at all. So what we get is a situation where the non-threading user is not disturbed but the threading user is seriously restricted. I've been following this list and played around some myself with ithreads in 5.8. There's a serious amount of overhead in using them. The programming model is twisted. This is obvious from the number of special packages that have been generated (mostly by the hard-working Elizabeth Mattijsen) to enable ithreads to be used effectively. Even the fork() emulation on Windows is lacking since the forked 'processes' aren't in fact separate manageable processes. Killing the main thread kills all ithreads, which includes what would on *NIX be separate processes. I may be wrong, but I believe that only one thread can issue a system() call at a time, or for that matter an exec() call. What scares me is that I believe that the Parrot/Perl 6 effort is moving down the same path. I really want many of the things that will go into P6 (such as the extension of regular expressions to handle recursive-descent parsing...wow!) but I also want 'real' threads. I don't mean to be bitching and moaning. A lot of great uncompensated work goes into Perl and I get a lot done with it. I'm thankful that there are so many smart people working on this. It's just...the only thing missing from Perl is threads. It would be good if Perl had them. I don't consider ithreads to be threads. But then I'm a crank...I don't consider Java interfaces to be a suitable replacement for multiple inheritance in objects either. I'm obviously swimming upstream there too. So sue me. I would note one silver lining to ithreads. They do in fact make for an appropriate computational model for a multi-processor system without shared memory space. I just don't find that immediately useful. > At GreenLight are trying to decide what to do in the future - retrofit > the old 5.005 code back into 5.10 and beyond or make significant > modifications to ithreads so that the 5.005 paradigm can be supported > (it isn't clear if the latter is possible). I suppose the moral, if there is one, is that I would want ithreads AND 5.005 threads to BOTH work. And while I'm at it I want to win $10M in a lottery... mma
