Date: Sun, 8 Jul 2001 10:43:56 -0500 From: David Leimbach <leimbacd@bellsouth.net> To: Gabriel Ambuehl <gabriel_ambuehl@buz.ch>, questions@freebsd.org Subject: Re: Passing data in C++ via stdin without waiting for the new process to complete Message-ID: <20010708104356.B5630@mutt.home.net> In-Reply-To: <84594262844.20010708173749@buz.ch>; from gabriel_ambuehl@buz.ch on Sun, Jul 08, 2001 at 05:37:49PM %2B0200 References: <114577608557.20010708130014@buz.ch> <3B484403.1BA9A21D@jak.nl> <84594262844.20010708173749@buz.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
fork and execl!!! execl replaces the current process. So fork then execl. man execl Dave On Sun, Jul 08, 2001 at 05:37:49PM +0200, 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. > > 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. > > 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 teh 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... > > Best regards, > Gabriel > > -----BEGIN PGP SIGNATURE----- > Version: PGP 6.5i > > iQEVAwUBO0hwQMZa2WpymlDxAQGhUwf/TGTbKLC8/htZ+duiD/gL6OYs38fK17U0 > kHohMw3EQ5fM/bK+kD34cfaWJyyqjCUgSo5NaGh9Vi2thalrippIi1GIh0AO0Q6s > hjj26+a0PT+qwHq6XglblFc6RB3VnW/0M4t2AHpoyNs8CHax/o/xsKbSWcfW/ODq > bD4eUcYxhu+f5RA5gsyofLczBkYAssz5At9bZVWTKwYHAonSzuUb0OfrdBCRK/Eg > IA1SAw8kI9TJJ/vz5C+ldKCG44u9Jm/ssTvHoJv5NOa1nNlkb2dGg6EwhB2eSsbx > fezrOd8UatPYfVFhU0OWY23s4B/aHuDb38oSkbShIrj8FS5qlFUnog== > =F3Lv > -----END PGP SIGNATURE----- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010708104356.B5630>