From owner-freebsd-questions Sun Jul 8 10:14:43 2001 Delivered-To: freebsd-questions@freebsd.org Received: from discus.nl.uu.net (discus.nl.uu.net [193.67.79.178]) by hub.freebsd.org (Postfix) with ESMTP id 25F1737B403 for ; Sun, 8 Jul 2001 10:14:39 -0700 (PDT) (envelope-from arjan@jak.nl) Received: from 1Cust212.tnt13.rtm1.nl.uu.net ([213.116.120.212]:1089 "EHLO jak.nl") by discus.nl.uu.net with ESMTP id ; Sun, 8 Jul 2001 19:14:21 +0200 Message-ID: <3B4894E8.4E9CDA6A@jak.nl> Date: Sun, 08 Jul 2001 19:14:16 +0200 From: Arjan Knepper Organization: JAK++ Software Development B.V. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Gabriel Ambuehl Cc: freebsd-questions@freebsd.org Subject: Re: Passing data in C++ via stdin without waiting for the new process to complete References: <114577608557.20010708130014@buz.ch> <3B484403.1BA9A21D@jak.nl> <84594262844.20010708173749@buz.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gabriel Ambuehl wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > Hello Arjan, > > Sunday, July 08, 2001, 1:29:07 PM, you wrote: > > > read : > > man -a 2 fork > > man -a 2 rfork > > man -a 2 vfork > > man -a 2 wait > > man -a 2 _exit > > man -a 3 exit > > man -a 2 dup dup2 > > Oh I've read all of those (except the dup() stuff). It's just that I > think > that all of the fork derivatives won't do me any good as they are > thought to fork another copy of the current process as does, for > example, > Apache 1.3 to achieve simultaneous handling of concurrent requests. > But I > need to spawn separate, distinct executables that perform their very > own tasks, not just a copy of the calling process. See man execve and friends, forgot to mention those in my first reply , but Dave Leimbach supplied those. > The exec() family of calls looks more promising, but those still > block the parent process. I need a solution, that allows the parent > process to continue its work immediately after the child has been > spawned, no matter how long it takes the child to complete. fork, execle or execve, dont waitpid, maybe sighandler for CHILD termination > One somewhat crazy way to circumvent the blocking of the parent would > be to use a separate thread to control each of the currently running > childs but > I fear that this would end up in a performance problem if each call > to > an external executable also involves creation of a thread in the > parent. > > Another approach, which perhaps would even be the faster one (how > compares fork() to the creation of a wholly new process from > scratch?), > is to simple create fork() based daemons out of the external programs > which then accept their params by TCP or UDP... > > > P.S Buy the book : "Advanced Programming in the UNIX environment" > > by W.R.Stevens ISBN:0-201-56317-7 and maybe his other books about > > "Unix Network Programming" as well. > > I've already got Volume 1 of Network Programming by Stevens right > beside me and didn't want to don't like C and thus use C++ (would > prefer Python but that is too slow and too separated from the System > for my current project) which at least got stuff like dynamic arrays > built into the STL so I don't have to come up with what I consider to > be essential data types... The book is not about C it is about the "NETWORK PROGRAMMING API ON UNIX" and since UNIX is entirely in C the API is in C. You may incorperate C system api calls in C++ as you may know. If you don't want to do any C-API stuff anyway, get a C++ libs from the ports which does al kind of wrapping around the UNIX system API for forks network etc see http://www.freebsd.org/ports/devel/ cppadvio-2.6, rudiments-0.20, CommonC++-1.4.1 etc. Again get the W.R. Stevens book and read chapter 8 en 10. See also the other mails from David and Fernando. I only do C++ and prefer to use the sys-api without wrapper-functions-libs. But they might be very useful to you. Good luck Arjan Knepper To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message