> Rather, I meant that Windows processes are comparable to > Unix processes (concurrent threads of execution in isolated address > spaces), and that Windows threads are comparable to Unix threads > (concurrent threads of execution in common address spaces). I'm not > an expert on Windows, but I do believe that those valid comparisons.
That's an incorrect comparison, Nico. I won't talk about all flavors of Unix but on Linux threads and processes are absolutely equal. That's why talks about what's better between threads and processes makes sense. In Linux creation of new process involves just a little bit more overhead compared to creation of new thread, and support of running thread is absolutely equal to support of running process. On Windows it's different - process is much more heavy-weight object than thread and involves much bigger system load to support it. There's an official general advice for Windows: better create a new thread in the same process than a new process. Regarding fork vs vfork (and thus posix_spawn): besides the fact that it applies only to the case of running new application (not to cloning the current process which fork is initially designed for) I don't understand your position. In Linux kernel these two are the same syscall and implementation of fork is quite straightforward whereas vfork part requires jumping through additional hoops. So I don't understand why one is better than other. BTW, vfork is strongly discouraged on Linux: http://tldp.org/HOWTO/Secure-Programs-HOWTO/avoid-vfork.html. Pavel On Sat, Feb 19, 2011 at 4:42 PM, Nico Williams <[email protected]> wrote: > On Sat, Feb 19, 2011 at 1:45 PM, Pavel Ivanov <[email protected]> wrote: >> Nico, it looks like your don't understand what you are saying. > > I think you misunderstood what I was saying. I think my wording could > easily have caused that: > >>> Windows and Unix processes and threads have similar semantics, and thus >>> roughly comparable performance envelopes. >> >> Windows processes and threads don't have similar semantics, unix >> processes (and threads) are not comparable to Windows processes at >> all. Just search the internet on this topic and look at some >> benchmarks. > > I didn't mean that Windows processes are comparable to Windows > threads. Rather, I meant that Windows processes are comparable to > Unix processes (concurrent threads of execution in isolated address > spaces), and that Windows threads are comparable to Unix threads > (concurrent threads of execution in common address spaces). I'm not > an expert on Windows, but I do believe that those valid comparisons. > >>> Threading is difficult, though certainly not impossible, to get right. Take >>> Richard's advice, avoid threading. >> >> All your email is about evilness of fork(). But fork() is >> process-related, not thread-related call. So you are suggesting that >> processes are evil too? Or are you suggesting that starting new >> process from your application by using fork() is evil? But exactly >> this call is used by any shell or other application starting new >> processes (or even a system() function). > > Wow, well, you did misunderstand me. I called fork(2) evil, but I > praised posix_spawn(3C), thus you should not have concluded that I > think processes are evil -- I did not pronounce an opinion on > processes earlier, but for the record: I don't think processes are > evil. > > I stand by my characterization of fork(2) and friends. > > Also, I do not think threads are evil. I do believe that threading > (that is, multiple concurrent threads of execution in a single address > space) is difficult to get right in any programming language (except, > perhaps, ones like Clojure). > > Nico > -- > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
