- Threads on Windoze (was Re: Let's call the <=> operator "trike") - 10 Updates
- Hello, on demand world - 1 Update
- I will stop writing on this forum - 1 Update
| red floyd <dont.bother@its.invalid>: May 21 05:05PM -0700 > a pipe/socket/fifo from a parent instead of just starting up normally when > both parent and child will start at main() ? Unless windows has some voodoo > magic then a command line switch is the only way to do it. Which is fugly. And what, exactly, is so horrible about this? SSHD does (or did...) exactly this. |
| boltar@cylonHQ.com: May 22 03:38PM On Mon, 21 May 2018 17:05:31 -0700 >> magic then a command line switch is the only way to do it. Which is fugly. >And what, exactly, is so horrible about this? SSHD does (or did...) >exactly this. If I have to explain why its an ugly hack there's little point discussing it. |
| boltar@cylonHQ.com: May 22 03:39PM On Mon, 21 May 2018 23:06:04 +0100 >> magic then a command line switch is the only way to do it. Which is fugly. >In the Linux world, return code from fork(). In the Windows world - why >would the child process be running the same exe as the parent? But if it Why wouldn't it be running the same exe? What do you think fork() does? >is can't it just look at its parent process? Look at it how, in a mirror, via skype? |
| red floyd <dont.bother@its.invalid>: May 22 09:22AM -0700 >> And what, exactly, is so horrible about this? SSHD does (or did...) >> exactly this. > If I have to explain why its an ugly hack there's little point discussing it. Nope. You're the one making an assertion without providing evidence. Therefore you are the one who has to back up the assertion. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: May 22 03:03PM -0400 On 05/22/2018 12:22 PM, red floyd wrote: >> If I have to explain why its an ugly hack there's little point discussing it. > Nope. You're the one making an assertion without providing evidence. > Therefore you are the one who has to back up the assertion. True - but "ugly" is a purely aesthetic judgment, and as such, entirely subjective (and as such, of little general importance). Therefore, the only relevant evidence is evidence about whether or not boltar actual considers it ugly. Do you have any reason to doubt that he's telling the truth about how he feels? If so, what evidence would you accept as supporting that claim? Now, if he were to modify his assertion to address objective features of that approach which cause it to seem ugly to him, you could reasonably argue about whether or not those features exist. But arguing about whether or not those features make that approach ugly is a waste of time. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 22 03:36PM -0400 > a pipe/socket/fifo from a parent instead of just starting up normally when > both parent and child will start at main() ? Unless windows has some voodoo > magic then a command line switch is the only way to do it. Which is .. I will break my rule to reply to this post. On the day you posted, I tried to send to your boltar@cylonHQ.com email address, but it bounced. I waited for additional replies, but none have come, so I will reply as I originally did: -----[ BEGIN: Original reply sent via email ]----- Windows has many utilities to allow a child process to access info the parent process needs to give it. Some are used more frequently, and others are not. Generally, create a window (not a graphics window, but a msg window to send/receive messages). In Windows the Window can be identified by class name. Find it, and send it a message asking for its new "marching orders" by its process id. The app which launched the new process maintained the launched process id, and any associated data the new process needs to receive. The newly spawned child process receives back a globally allocated memory block which it can use to obtain all of the instructions you need to pass it, including the handles of pipes, names of pipes, socket information, etc. It parses that structure and has every piece of information it needs to conduct its child work. This all takes a few milliseconds to startup, probably less time than it took for Windows itself to launch the process. No voodoo. No magic. Straight-forward design. You can also pass information on the command line to make the FindWindow() function not required, such as passing the hex value of the HWND to the message window directly as text. Windows (at its core design) is a very very robust kernel. It is only all the fluff on top that makes it obfuscated from the user's (and often developer's) point of view. -----[ END: Original reply sent via email ]----- -- Rick C. Hodgin |
| Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: May 22 09:42PM +0200 >> In the Linux world, return code from fork(). In the Windows world - why >> would the child process be running the same exe as the parent? But if it > Why wouldn't it be running the same exe? Because in most cases, the child process serves a different purpose than the parent. >What do you think fork() does? It creates a copy of the current process, which in most use cases is immediately disposed afterwards by calling one of the exec() variants. Creating that unwanted copy may be expensive in the first place, depending on the OS and MMU architecture. And it has ugly side-effects for programs dealing with a lot of open handles, especially socket handles. Windows takes a more direct approach by always creating a fresh process, running an arbitrary exe, passing over only explicitly specified information through command line parameters, pipes, or environment variables. |
| Vir Campestris <vir.campestris@invalid.invalid>: May 22 09:38PM +0100 > Why wouldn't it be running the same exe? What do you think fork() does? >> is can't it just look at its parent process? > Look at it how, in a mirror, via skype? There's an old saw - Know your enemy. You seem to think Windows is your enemy. You ought to know it better. Windows has an API to get the parent process. This is too far OT. Bye. Andy |
| Paavo Helde <myfirstname@osa.pri.ee>: May 23 12:55AM +0300 On 22.05.2018 22:42, Hergen Lehmann wrote: >> What do you think fork() does? > It creates a copy of the current process, which in most use cases is > immediately disposed afterwards by calling one of the exec() variants. This is a point where one must strictly choose either multi-threading or multi-processing. As soon as there is a possibility that you have more than one thread in the parent process, you cannot use fork without immediate exec any more. This is because fork only duplicates a single thread. Another thread in the original process may e.g. hold a global mutex lock in malloc which nobody is going to release in the forked process. This is not a theoretical issue. The idea of a zero argument fork() vs 10-argument CreateProcess() seems appealing, but one should realize its appeal is strictly limited to single-thread processes. As soon as you have a multi-threaded process you need to call exec very soon after fork, and you are limited to dup2^H^H^H^H a strict subset of C functions between fork and exec. In short, the fork mechanism does not suit C++ very well (especially after C++11 officially recognized the existence of threads). |
| Melzzzzz <Melzzzzz@zzzzz.com>: May 22 10:03PM > between fork and exec. In short, the fork mechanism does not suit C++ > very well (especially after C++11 officially recognized the existence of > threads). You either use threads or processes. There is no point in using both threads and fork, except as you noted when exec-ing from multi-thread process. -- press any key to continue or any other to quit... |
| woodbrian77@gmail.com: May 22 10:15AM -0700 > six months on your project if we use my software as > part of the project. There are more details here: > http://webEbenezer.net/about.html I'll take what I can get regarding the above, but this: http://www.israelnationalnews.com/Articles/Article.aspx/22184 has rekindled my desire to work with Israelis. I grew up around farmers and appreciate the reminder to have respect for them. Brian Ebenezer Enterprises http://webEbenezer.net |
| Bonita Montero <Bonita.Montero@gmail.com>: May 22 09:51AM +0200 Am 21.05.2018 um 16:55 schrieb Sky89: > Don't bother, i am not destructing this forum, it is easy > for me to stop from writing on this forum of C++ and > i will do it now, i will stop writing on this forum. Go to a doctor and get help! Youre obviously manic. |
| 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