From: Chris Thomas Date: 2002-01-19T03:36:13+09:00 Subject: Re: A few words on threads On 1/18/02 9:18 AM, ";" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > In article <1011204066.634998.2706.nullmailer@ev.netlab.jp>, > Yukihiro Matsumoto wrote: >> Hi, >> >> In message "A few words on threads" >> on 02/01/17, "Avdi B. Grimm" writes: >> >> |P.S. Does anyone here have any theories on /why/ threads >> |are still percieved as such an arcane topic in the UNIX and >> |scripting language communities? >> >> For scripting language community, it's probably because implementing >> an *efficient* thread safe interpreter (and its extension libraries) >> is so difficult. >> > > - - There are real problems with threads and unix in general. > Dealing with signals is difficult. Dealing with large data > structures is can be a problem. Debugging can be a nightmare. > None of these problems are that difficult to solve for a single > OS or a single program, but you have to design it in from the > beginning. It really hasn't been that long that you could > count on a consistant thread API on a unix platform. > - - I think if you say compare objects in say Ruby and Perl, it's > clear that there are certain things that you can't just > "bolt on after". I think threads in a interpreted language > is one of these things. The failure of threads in Perl5 I > think was one of the motivating reasons behind Parrot. > - - I happen to agree with Tom Christenson when he rants about > threads being overrated. They are a powerful tool and can be > a big win in certain situations[1], but fork provides a much > more robust tool that is entirely sufficient for most > applications on a Unix box. There is nothing you can do > with threads that you can't do with fork, it's just slower > and safer. I have to disagree with this absolute statement. Especially as a user of an interpreted language commonly used as an integration tool, you probably don't have control over the architecture of your operating environment. There are things you can't do by forking in some environments that you *can* do by threading. Processes and threads are different constructs, useful for different purposes, and, ideally, both should be available. Chris