- Niuce C++14-feature - 6 Updates
| Manfred <noname@add.invalid>: May 24 04:58PM +0200 On 5/24/2021 3:21 PM, David Brown wrote: > efficient than multi-processing, or that it is more common - I am merely > disagreeing with your blanket generalisations about multi-threading > /always/ being better and /always/ being used. The difference between fork and threads is not just how much they cost in terms of resource consumption. Their memory model is obviously and fundamentally different, and that's what drives the design choice between them. In the design of a service that must serve clients on different connections it's very common that you don't /want/ to share the same process space among all clients, because of a number of reasons ranging from security to process robustness to design efficiency. sshd and postgresql have been mentioned, other examples are file servers, wherein the natural choice for synchronization is at the filesystem level. I'm sure many more examples exist. It's clearly no coincidence that fork() serves this kind of purpose pretty well, and that it was designed this way in the *nix world. However the benefit of a multiprocess design is not only for server code. Even in a single user scenario the design of a complex system with dozens of tasks may very well choose a multiprocess solution especially if system stability is a primary requirement, where you don't want a fault in one function to compromise the whole system. I've seen this happen even under Windows. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 24 06:14PM +0200 > How can threading be easier to write when you have to worry about locking > and race conditions, vs fork() which is fire and forget if you don't need > inter process synchronisation? If you don't need synchronization you won't need it for fork()ing #and threading as well. Then you simply could fire a thread with thread( func, params ... ).detach() and forget the thread. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 24 06:15PM +0200 > So what? Do you ever manage to understand the point for anything? Is it an > English comprehension problem? I've shown that fork()ing is much more slower than to create a thread. And even more a lot slower when pages are CoWd. |
| David Brown <david.brown@hesbynett.no>: May 24 06:51PM +0200 On 24/05/2021 16:58, Manfred wrote: > if system stability is a primary requirement, where you don't want a > fault in one function to compromise the whole system. > I've seen this happen even under Windows. A clear example of that last point would be browsers, where forking means that plugins, extensions, tabs, etc., can crash without bringing down the whole browser. It costs - especially in ram - but you get benefits from it. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: May 24 02:51PM -0400 On 5/24/21 6:54 AM, Juha Nieminen wrote: ... > They say "don't feed the troll". There seems to be plenty of feeding the > troll in this thread. > At least I restricted myself to merely insulting the troll. Paying attention to a troll, whether negative or positive, IS how you feed them. They thrive on attention. They deliberately try to provoke negative reactions, and enjoy them. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 24 01:33PM -0700 On 5/24/2021 3:44 AM, Bonita Montero wrote: > But usually they're used alone when there's no contention when > also employing a CV. A mutex plus a CV is almost the fastest > producer-consumer-mechanism (monitor-objects are the fastest). Is that a troll? |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment