- Niuce C++14-feature - 19 Updates
- Why does this work in MSVC 2019... - 2 Updates
| MrSpook_uc82glu@4o0o4n889yatl8.ac.uk: May 20 08:19AM On Wed, 19 May 2021 16:15:20 GMT >> dump. >This is a classic case of first trying to explain away a basic mistake >that you aren't man enough to admit to and then an attempt to backtrack. What basic mistake? The bug was real. You can jump on the bandwagon and try and claim it didn't based on no knowledge whatsoever but it won't change anything so knock yourself out. >No, no C++ compiler has ever used the pure specifier as a function pointer. And your source for this is .... |
| MrSpook_nkfcgvl@7o616.biz: May 20 08:23AM On Wed, 19 May 2021 13:39:58 -0700 >> Oh ok. So explain how you'd implement an atomic futex in userspace that say >> was used to implement a semaphore that other processes would use. >Oh, I cannot do that in pure C/C++. Only Intraprocess. Quite. >language >> whether it be C or C++. >If a compiler says it supports C/C++11, then C/C++11 code should run on it? If it says the entire spec then yes. >I am not exactly sure what you mean, but Windows has a futex like >mechanism. I cannot remember if they can be used for interprocess >communication: I was talking about multi process in general. If C++ supports threads why doesn't it support multi process too? My theory is because of the broken windows process model - any lowest common denominator API would be next to useless on unix. As it is C++ threads don't support 3 level locking (unless its been added recently) like posix threads do which makes them useless for certain use cases. |
| Paavo Helde <myfirstname@osa.pri.ee>: May 20 12:38PM +0300 > doesn't it support multi process too? My theory is because of the broken > windows process model - any lowest common denominator API would be next to > useless on unix. The issue with posix style process creation (fork()) is that it does not play well with multithreading. Fork() creates a new process out of a single thread in the old process, but inherits all the memory space of the old process, including any mutex locks currently held by other threads. As in the new process these other threads do not exist, nobody will release these locks and the process can easily deadlock. Even if the locks could be released somehow (e.g. by pthread_atfork() or otherwise) the data structures they protected might easily remain in an inconsistent state. This is a direct quote from "man fork": "After a fork() in a multithreaded program, the child can safely call only async-signal-safe functions (see signal-safety(7)) until such time as it calls execve(2)." So what we effectively get is pretty similar to the Windows process creation model: a lot of complicated setup with limited functionality, and a new fresh process started with a new executable. Thus one may argue it's the posix process creation model which is broken and does not fit well the current multithread-dominated software design. One might try to limit multi-processing to single-thread programs only and getting fork() to work in Windows, but in practice this is not possible, even the simplest Hello World program immediately gets invaded by foreign threads created by antiviruses and shell extensions. I don't like this either, but there you are. |
| Manfred <noname@add.invalid>: May 20 12:16PM +0200 On 5/19/2021 7:41 PM, Scott Lurndal wrote: > You have slipped a few times and posted under your real > name Christopher aus Deutschland. You know "Christopher aus Deutschland" means Christopher from Germany, right? |
| Bonita Montero <Bonita.Montero@gmail.com>: May 20 12:31PM +0200 >> name Christopher aus Deutschland. > You know "Christopher aus Deutschland" means Christopher from Germany, > right? I'm from Germany but I'm not Christopher. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 20 12:33PM +0200 >> You know "Christopher aus Deutschland" means Christopher from Germany, >> right? > I'm from Germany but I'm not Christopher. And there aint any Christophers in Germany as the name is called Christoph or Christof here. |
| MrSpook_f4@x4dcxggdi.eu: May 20 01:42PM On Thu, 20 May 2021 12:38:37 +0300 >the locks could be released somehow (e.g. by pthread_atfork() or >otherwise) the data structures they protected might easily remain in an >inconsistent state. This is a direct quote from "man fork": That may be so, but you could argue it the other way around - threads don't play nicely with multi process and the latter is far more useful as multi process can do everything that threading can do - albeit not as efficiently in some cases - but threading definately cannot do everything multi process can do. >Thus one may argue it's the posix process creation model which is broken >and does not fit well the current multithread-dominated software design. I disagree. The windows process model which starts a new process from the beginning each time with no state carried over (except for command line args) is extremely limited in its usefulness. Posix can do that plus fork at a given point with the new process being a carbon copy of the old one except for the return value from fork(). >One might try to limit multi-processing to single-thread programs only >and getting fork() to work in Windows, but in practice this is not I've been told, though I've never seen it in action, that the windows kernels can do something like fork() but the win32 API doesn't expose it. >possible, even the simplest Hello World program immediately gets invaded >by foreign threads created by antiviruses and shell extensions. I don't Sounds like Windows runtime is profoundly broken if that happens outside of the control of the program. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 20 04:20PM +0200 > beginning each time with no state carried over (except for command line args) > is extremely limited in its usefulness. Posix can do that plus fork at a given > point with the new process being a carbon copy of the old one ... This is good for nothing. |
| scott@slp53.sl.home (Scott Lurndal): May 20 02:35PM >> name Christopher aus Deutschland. >You know "Christopher aus Deutschland" means Christopher from Germany, >right? Ich hab ein bischen deutsch, hab sich? |
| MrSpook_5Xl@m9q7d5ux5tl8o5.co.uk: May 20 02:38PM On Thu, 20 May 2021 16:20:24 +0200 >given >> point with the new process being a carbon copy of the old one ... >This is good for nothing. Keep demonstrating your ignorance, its very amusing :) |
| Manfred <noname@add.invalid>: May 20 06:37PM +0200 On 5/20/2021 12:33 PM, Bonita Montero wrote: >> I'm from Germany but I'm not Christopher. > And there aint any Christophers in Germany as the name is > called Christoph or Christof here. Glad to hear, however your real identity is of little interest to me (no offense, it's just that I am interested in /what/ gets posted rather than /who/ the poster is) I was only wondering if Scott's assumption that "Christopher aus Deutschland" would be a real name was due to some lack of familiarity with the German language - apparently it's not, however I'll leave it at that. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: May 20 01:10PM -0400 On 5/20/2021 12:33 PM, Bonita Montero wrote: > And there aint any Christophers in Germany as the name is > called Christoph or Christof here. Interesting - so visitors to Germany named Christopher automatically get renamed on entry? By the same logic, would I automatically become Jakob Kuyper if I visited Germany? I did spend a few hours in Germany on my way to Italy for my honeymoon - but no one informed me that my name had been changed for the duration of my visit. And since "there aint any", I presume that there's also some kind of legal barrier to prevent people from naming their Children using non-German spellings? |
| Mr Flibble <flibble@reddwarf.jmc>: May 20 05:43PM On Thu, 20 May 2021 14:38:16 +0000, MrSpook_5Xl wrote: >>> point with the new process being a carbon copy of the old one ... >>This is good for nothing. > Keep demonstrating your ignorance, its very amusing :) Do you even know why fork() actually exists? Because back in the day THREADS weren't a thing. If you want to COPY lots of program state using fork() then why the fuck aren't you using threads? Processes are heavyweight OS primitives compared to threads. These days fork() and associated horribleness like Linux's overcommit are an anachronism. /Flibble |
| Mr Flibble <flibble@reddwarf.jmc>: May 20 05:46PM On Thu, 20 May 2021 08:19:47 +0000, MrSpook_uc82glu wrote: >>No, no C++ compiler has ever used the pure specifier as a function >>pointer. > And your source for this is .... You are the one making the original claim so you provide a source first, mate. Until then I will rely on common sense and Occam's Razor. /Flibble |
| scott@slp53.sl.home (Scott Lurndal): May 20 05:56PM >And since "there aint any", I presume that there's also some kind of >legal barrier to prevent people from naming their Children using >non-German spellings? Or, I was in a hurry, and didn't recall the exact spelling used when Bonita/Christoph slipped and posted under his real name a few months ago. A rose by any other name.... |
| Branimir Maksimovic <branimir.maksimovic@gmail.com>: May 20 06:02PM > possible, even the simplest Hello World program immediately gets invaded > by foreign threads created by antiviruses and shell extensions. I don't > like this either, but there you are. Normaly one don't do threads and forks togather. Always was like that, except fork/exec (some execuatble) like cgi_bin in web server... -- current job title: senior software engineer skills: x86 aasembler,c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... |
| Bonita Montero <Bonita.Montero@gmail.com>: May 20 08:26PM +0200 > Interesting - so visitors to Germany named Christopher automatically get > renamed on entry? ... You're really stupid ! That's not what I said. I just said that Germans get the name Christoph or Christof and not Christopher. |
| scott@slp53.sl.home (Scott Lurndal): May 20 07:23PM >> like this either, but there you are. >Normaly one don't do threads and forks togather. Always was like that, >except fork/exec (some execuatble) like cgi_bin in web server... When threads were first introduced to SVR4 (with SVR4.2MP), they added a 'forkall(2)' system call, which in addition to the normal fork(2) operations, would copy all the light-weight processes (LWP) which implemented the kernel threads. A user-level M:N thread model was implemented that used N LWPs and M user-level threads (where M doesn't necessarily need to match N). Linux never implemented that model (although green threads were close) chosing instead to use a light-weight process (clone) 1:1 model. Digital Unix had their own threading model (Dave Butenhof) which was in many ways the genesis of the Posix 1003.4 pthread interfaces. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 21 12:07AM +0100 On Thu, 20 May 2021 19:23:38 GMT > Digital Unix had their own threading model (Dave Butenhof) which > was in many ways the genesis of the Posix 1003.4 pthread > interfaces. This is more a posting to those who preceded you than to you: there is an irresoluble conflict about what you do when a multi-threaded process forks. There are only two approaches: you fork the process with all threads included, or you fork the process with one thread (the forking thread) included. Either approach leads to your code being in an undecidable state, because forking is asynchronous with respect to the non-forking threads. There is discussion of the issue (in connection with the useless attempt to square the circle with pthread_atfork()) by the man himself here: https://groups.google.com/g/comp.programming.threads/c/ThHE32-vRsg/m/3j-YICgSQzoJ So don't fork a multi-threaded process after other threads are running unless you intend to exec immediately after, and where you do intend to exec, do your setup (except for setting up pipes) in the forking thread before forking and not in the child. Where you definitely need multiple processes in a multi-threaded program, fork before you launch other threads and communicate with the child process via pipes. Then you will be OK. |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: May 20 03:44AM +0300 On 5/18/2021 2:05 AM, Chris M. Thomasson wrote: > I don't think this should work at all! It should segfault. This statement makes no sense whatsoever. "Segfault" is typically a specific manifestation of undefined behavior. There's no "should" about undefined behavior. -- Best regards, Andrey Tarasevich |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 19 08:38PM -0700 On 5/19/2021 5:44 PM, Andrey Tarasevich wrote: > This statement makes no sense whatsoever. "Segfault" is typically a > specific manifestation of undefined behavior. There's no "should" about > undefined behavior. Well, yeah, you are right. |
| 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