Skip site navigation (1)Skip section navigation (2)
Date:        Sun, 08 Jul 2001 19:14:16 +0200
From:      Arjan Knepper <arjan@jak.nl>
To:        Gabriel Ambuehl <gabriel_ambuehl@buz.ch>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Passing data in C++ via stdin without waiting for the new process  to  complete
Message-ID:  <3B4894E8.4E9CDA6A@jak.nl>
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
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B4894E8.4E9CDA6A>