RE: question: spawning processes in a Unix c++ application
- From: "Ken Perry" <whistler@xxxxxxxxxxxxx>
- To: <programmingblind@xxxxxxxxxxxxx>
- Date: Fri, 18 Dec 2009 18:11:23 -0500
The reason for the case statement is you are in both the child and the
parent process. If you look at it this way that as soon as it hits that
fork statement your code file becomes two identical code files. One is set
to 0 and one is set to 1 so the logic then goes on from there. As for the
pipe you need to be able to send on one pipe and receive on the other so you
don't get in some kind of grid lock which is why she told you to do it that
way. 1 is a pipe and 0 is a pipe so you have to know that the child will
send on one and receive on the other and visa versa on the parent.
Now with that all said you don't really need to do any of this. If your
already running a mud what you can do is have the web service telnet in and
send a special character set that says I am a web server. From then on you
deal with that descriptor different. Instead of sending straight text you
can wrap it in xml.
Now there is another way to do this as well. If you were using a database
as your file system you could pull the information straight from the
database rather than interacting with the socket code. So you could use
something like php to pull from the database. I am guessing you are wanting
to put player stats, clan info and things of the like so that could be done
all by database calls.
Ken
-----Original Message-----
From: programmingblind-bounce@xxxxxxxxxxxxx
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Tyler
Littlefield
Sent: Friday, December 18, 2009 11:34 AM
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: question: spawning processes in a unix c++ application
Hello laura,
thanks for the info, this really helps clarify things; I have a couple of
questions.
From what I understood, pipe creates an array of two dementions, 0 is input
and 1 is output or however you decide to use them. so, couldn't you just
send data to 0 and it would end up on the output end of the pipe?
Second, I don't really understand what your fork statement there does. I
know fork spawns another process, but I'm not quite sure what the whole case
0: //parent process
bit was about. If you fork your going to be in the child process, no?
Thanks,
On Dec 18, 2009, at 8:46 AM, qubit wrote:
> Hello Ty -- back on unix again?
> As long as you are on the same server you can fork an independent process
to
> do what you want -- of course if you are looking at 2 systems with a
network
> connection, you wouldn't use fork, but rather start two process manually,
> one on each side.
>
> The following took a little time to type... Hmm Hope it is useful to
> someone -- maybe I should put it in a tutorial on the website. I'll see
if
> there is something about unix software development that hasn't been
written
> yet and post it.
> *******
> I have in my possession a game I wrote for my nephew when he was small.
It
> consists of a main board process and 5 players -- 4 computer generated
> monsters and one human player. All the monsters were spawned as
independent
> processes, as was the player. The only difference between the player
> process and the monster processes was that the monsters communicated with
> the main board which would send it board state info, and the monster
> processes would then submit moves. The player process only communicated
the
> users moves to the main board, which assumed the player didn't need the
> state information.
>
> Anyway, the seedy little reproductive details of the processes of the game
> were as follows (pseudo code):
>
> /* note: pipe returns a tiny array of 2 integer file identifiers.
> player_fd[0] is the front of the queue where moves are communicated -- it
is
> input from the point of view of the main process, so it should be read.
> player_fd[1] is the rear of the queue where data is written.
> Now if you want to write from child's stdout to be read by the main
> process's input at the other end of the pipe, you have to somehow tie
stdout
> in the child to the rear of the player_fd pipe. How do you do that? This
is
> a twisted little trick. The secret is that stdin and stdout and stderr are
> in a global space that is inherited by the child process even after it
calls
> exec. exec does not overwrite this data. This means that the parent and
> child processes can set up any environment it wants, including command
line
> arguments to main, before calling exec to start the child.
> Noe for some pseudo code:*/
>
> // globals in file main.c
> //file descriptors associated with player and monsters -- note, monsters
> communicate 2 ways so need 2 descriptors
> static int player_fd = -1;
> static int monster_fd[4][2] = { { -1, -1}, { -1, -1 }, { -1, -1 },
> { -1, -1 } };
>
> int pid, mid[4]; // process ids of player and monsters
>
> // This function will fork and exec the player process
> spawn_player() {
> p = create a pipe -- I forget the syntax
> pid = fork()
> switch (pid) {
> case -1: fatal error
> case 0: // parent process
> // you are in the parent; close dangling end of pipe and return
> close(p[1]);
> player_fd = p[0];
> // note that rear of pipe is duplicated in the child process and
the
> id will not be used by the parent process, so we close it.
> return
> default: // you are in a new process with process id == pid.
> // set up pipe the way you need it before exec
> // Note: stdin, stdout and stderr have file descriptors of 0, 1 and
> 2 in all new processes.
> // When you close stdout, you are freeing up number 1 to be used in
> the next file allocated -- in this case, the dup operation will set stdout
> to be the rear of the pipe.
> close(1) // stdout's process id
> dup(p[1]) -- this will allocate a new file 1 (stdout that will
point
> to the rear of the pipe)
> close( p[0]) close(p[1]); // these are duplicates that hang onto
> resources.
> exec("player"...)
> }
> }
>
> I'll leave it as an exercise to write the spawn_monster function.
> Be sure to keep straight the nitty little differences between the ends of
> the pipe -- pipe[0] is always front, pipe[1] is always rear.
> Also keep process ids distinct from file ids.
> Hint: monsters need 2 pipes instead of one -- there is the move pipe where
> the monster writes info to the main process, and the info pipe which is
used
> by the main process to send info to the monster.
> .
>
> Please reply with questions and I'll compile this with other things to
post,
> if needed.
> Happy hacking.
> --le
>
> ----- Original Message -----
> From: "Tyler Littlefield" <tyler@xxxxxxxxxxxxx>
> To: <programmingblind@xxxxxxxxxxxxx>
> Sent: Thursday, December 17, 2009 11:52 PM
> Subject: question: spawning processes in a unix c++ application
>
>
> Hello all,
> I understand the basics of how fork works, but here's what I'm trying to
do;
> maybe someone can give me a bit of a push in the right direction.
> I have a server that will be working with two interfaces, a telnet
interface
> and a web interface. The telnet interface being part of the mud is already
> built in, but I would like to add in a web interface that would allow for
> viewing of generated data.
> What my idea was, was this:
> I want to somehow create a pipe that will allow for me to transport data
> back and forth between the server. I don't see why I should need to create
> two separate applications to serve one purpose, I would like to somehow
> spawn a new process from within the main server that will allow me to keep
> the pipe open and send/receive requests through it. Basically the server
> will send the data, and the web interface will generate the data, which
will
> remove a lot of work off the mud its self.
> Can this forking easily be accomplished? I assume I could open the pipe
and
> then fork from within a web initialization function toward the top of the
> code and then wait for a signal through the pipe to notify the web server
> that it can start the listening process, but I'm not quite sure how all
this
> would work.
>
> Thanks,
>
> Tyler
>
> __________
> View the list's information and change your settings at
> //www.freelists.org/list/programmingblind
>
> __________
> View the list's information and change your settings at
> //www.freelists.org/list/programmingblind
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
Other related posts:
