On Sat, Aug 20, 2011 at 06:06:04PM +0200, Bernd Petrovitsch wrote: > On Sam, 2011-08-20 at 10:00 -0400, Rich Felker wrote: > > On Sat, Aug 20, 2011 at 01:37:23AM +0200, Bernd Petrovitsch wrote: > > > > Multiprocessing can accomplish *some* of the same things, but not all, > [....] > > > > Note that just using threads does not commit you to making heavy use > > > > of memory sharing. You can still write your code very similar to how > > > > > > Ooops, threads share the whole (virtual) memory by design. > > > > That does not mean you have to use it at all. It's completely possible > > to write a multi-threaded program where each thread never accesses any > > object except its own automatic variables and memory it allocated > > itself with malloc. The only cases I can think of where memory virtual > > .... and free()d at some time. > Of course it is possible. But (all of) the (current and future) > programmer(s) have to think of that and - and that's the main problem - > if someone violates that rule, it can't be detected immediately > automatically.
Most contract violations are not immediately detectable in C. But unless you're abusing global variables (bad) or already clobbering memory (beyond bad), it's rather hard to unintentionally cause your threads to interfere with each other. > BTW if a thread uses only automatic variables (and self-malloc()ed > etc.), if can also use fork() - which is quite cheap - equivalently and > loose all of the above risks. No, then it has to deal with child processes, pids, wait, signal handling, the possibility of one process getting killed out from under it, etc. Using processes involves *more* global state than threads, not less. Then you also have to consider memory usage. If thread-like processes are going around forking all the time, the child ends up with a duplicate of the parent's memory, including all malloc allocations. Freeing this all is non-trivial and requires really ugly entanglements between modules. If you don't free it but continue this pattern of forking from arbitrary points in the program, you'll exhaust commit charge and/or virtual address space in some of your children. Rich _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
