Nico, it looks like your don't understand what you are saying. > 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. > 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). <threading rant> Can I suggest for everybody to stop this holy war about threads vs processes on this list? I see too many statements "don't use threads, use processes" that come before one even tries to listen to reasons why threads are actually used. That's not a good advice in such situation. I understand that developing multi-process applications could be much easier than multi-threaded ones (because you leave worrying about all multi-threading stuff to other developers, the ones who develop OS kernels), I understand that general advice to somebody not knowing anything about threads is to not use them. But it's not advice to absolutely any application out there. In many applications you can't reach the same level of performance with multi-process structure as you can with multi-threaded one. And using IPC and forks can make developer's life much harder than using simple mutexes and reading/writing to the same memory. So as this list is not for analyzing of pros and cons of threading vs processes for each application let's not bring this holy war here and leave it for some other list. </threading rant> Pavel On Fri, Feb 18, 2011 at 8:34 PM, Nico Williams <[email protected]> wrote: > On Feb 18, 2011 6:16 PM, "Samuel Adam" <[email protected]> wrote: >> FYI, Windows NT is documented to have light threads and heavy processes. > > Windows and Unix processes and threads have similar semantics, and thus > roughly comparable performance envelopes. > >> To my knowledge, it just was not designed with the goal of *nix/Plan 9/et >> al.’s more-or-less cheap and easy fork()/exec(). > > fork(2) is most certainly NOT light-weight, kernels having to jump through > hoops to make it perform well sometimes. Indeed, fork(2) is evil because it > is very, very difficult (though usually not impossible) to make layered > software fork-safe. > > If at all possible use posix_spawn(3C) instead of fork(2)/exec(2)! That > interface typically uses vfork(2) under the covers, which, though evil > itself, is much less evil than fork(2) when used properly (and > posix_spawn(3C) does use vfork() correctly). vfork() has the advantage of > having much safer semantics than fork() and also being much, much > lighter-weight. There's no need to worry about making code safe with > respect to posix_spawn(). > > [forkall(2) is the most evil of that family of Unix system calls, as it is > impossible to make code forkall()-safe, and when it works it is purely > because the parent exit()s quickly enough that nothing bad happens, but even > then forkall() is an accident waiting to happen.] > > Threading is difficult, though certainly not impossible, to get right. Take > Richard's advice, avoid threading. > > Nico > -- > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
