RE: question: spawning processes in a Unix c++ application
- From: "Ken Perry" <whistler@xxxxxxxxxxxxx>
- To: <programmingblind@xxxxxxxxxxxxx>
- Date: Sat, 19 Dec 2009 01:10:59 -0500
It all depends on how you code the mud you need to realize that a database
like mysql actually replaces your memory so for example if you did it right
players wouldn't have to save their player record would be kept up to date.
Can you imagine if you had to save every time you used a credit card? I
have been slowly switching from the memory model to the database model and I
would hate to see you go down the road where some of us old mud coders have
already been only to find that 10 years down the road you have to back out
to get some of the benefits of new technology. I have been playing with
making my mud a full web service using wsdl files and mysql that way you
could both play it with a web browser and play it on telnet through a client
service. Ah the fun of re-writing code.
Ken
-----Original Message-----
From: programmingblind-bounce@xxxxxxxxxxxxx
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Tyler
Littlefield
Sent: Friday, December 18, 2009 7:43 PM
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: question: spawning processes in a Unix c++ application
hello ken,
I had planned on using the pipe for the reason that I could generate data
on-the-fly and show up-to-date quest info and such, without having to make
sure the player was saved. I also wanted that the website can easily update
the rooms and zones and they'd be set up as the update was made on the mud.
I'm still working with flat-files, because I have yet to find a good xml
library. tinyxml sort of worked, but it was really hard to figure out.
Thanks,to make an olc system web-based, so
On Dec 18, 2009, at 4:11 PM, Ken Perry wrote:
>
>
> 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
__________
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:
