Parent & child accessing global variable
Okay, I've asked this same question in the usenet comp.unix.programmer newsgroup, but will go into more detail here.
I have a server which waits until it receives requests from clients. When this happens, a fork() occurs and the child process is told to deal with the request. This way, the server can wait for more incoming requests without delay.
I have a global variable which is a linked list of a struct which I have declared, the child process makes alterations to the variable, but these changes are not saved/seen once the child exists - I understand that a child process created with the fork keyword cannot access it's parents data space.
Is there anyway I can somehow overcome this hurdle?
I've been told to send the data from the child to the parent via a pipe, but this would mean that the parent process would have to wait or detect when the child process has finished ...
Any ideas?
Thanks in advance.
Chris.
I have a server which waits until it receives requests from clients. When this happens, a fork() occurs and the child process is told to deal with the request. This way, the server can wait for more incoming requests without delay.
I have a global variable which is a linked list of a struct which I have declared, the child process makes alterations to the variable, but these changes are not saved/seen once the child exists - I understand that a child process created with the fork keyword cannot access it's parents data space.
Is there anyway I can somehow overcome this hurdle?
I've been told to send the data from the child to the parent via a pipe, but this would mean that the parent process would have to wait or detect when the child process has finished ...
Any ideas?
Thanks in advance.
Chris.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
How could I determine whether the child is done though ...?
How would the parent know that the child has finished processing and is ready to send the linked list accross?
Would I have to use some for of IPC?
Thanks for your help
Chris.
How would the parent know that the child has finished processing and is ready to send the linked list accross?
Would I have to use some for of IPC?
Thanks for your help
Chris.
You could have the child send a signal to indicate it was through
or you could use IPC. Also you could have some kind of record or byte string to send through the pipe to indicate it.
or you could use IPC. Also you could have some kind of record or byte string to send through the pipe to indicate it.
ASKER
Hi, thanks for your advice.
I'm not 100% sure this is going to work though.
My code looks something like this in pseudo-code
for(;;){
wait_for_network_connectio
// via accept keyword
fork() and child processes_received_client_
} ;
Most of the time, the program will be waiting for a new request from a client and will only be in a position to check whatever's in the pipe or the status of the child when a new connection has been accepted .. this isn't really how I'd like things to be done. Ideally, the linked list would be updated as soon as possible...
Do you understand what I rambling on about?!?!
Perhaps I'm not using the correct approach?
Thanks again for your time.
Chris.
I'm not 100% sure this is going to work though.
My code looks something like this in pseudo-code
for(;;){
wait_for_network_connectio
// via accept keyword
fork() and child processes_received_client_
} ;
Most of the time, the program will be waiting for a new request from a client and will only be in a position to check whatever's in the pipe or the status of the child when a new connection has been accepted .. this isn't really how I'd like things to be done. Ideally, the linked list would be updated as soon as possible...
Do you understand what I rambling on about?!?!
Perhaps I'm not using the correct approach?
Thanks again for your time.
Chris.
I think I understand what you are trying to say.
Instead of 'waiting ' for a connecetion you can check for it. this way you are not stuck waiting for it and can do other things This should not be a prob as long as you don't get stuck waiting for anything to get done.
Instead of 'waiting ' for a connecetion you can check for it. this way you are not stuck waiting for it and can do other things This should not be a prob as long as you don't get stuck waiting for anything to get done.
ASKER
Hi,
Can you tell me how I can check for a connection?
All this hassle ... just because a child process can't access it's parents global variables ...
Looks like Linuxs' clone() would be ideal ...except I'm not using Linux ;-(
Can you tell me how I can check for a connection?
All this hassle ... just because a child process can't access it's parents global variables ...
Looks like Linuxs' clone() would be ideal ...except I'm not using Linux ;-(
Hi Dufus1,
You asked if your approach could be changed, here are a couple of suggestions below. I think the approach you are taking using pipes is not really practical. You are going to have two-way pipes to each and every child you fork which will make your program extremely complicated/messy (doing selects incrementally on socket and pipe file descriptors) and invariably impossible to maitain assuming that you are forking children to handle connections because you could have a number of concurrent connections (and associated child processes).
Why don't you use a blob of shared memory instead ? You need to take a guess at how big you want this blob to be; You could use this blob as an array of structures as opposed to a linked list. The advantage of using shared memory is that you can have any process attach to this blob and use it as if it were local to it. You should now worry about locking/unlocking on this blob since concurrent processes would be updating it (which would be the case anyway).
This is a typical problem of synchronization in a shared environment since the very reason you need a seperate process to handle each connection is that there could be multiple concurrent connections and any number of children could want to modify the list at any given time. Before you take on a job of this sort, you DO need to have an understanding of UNIX IPC.
A very much better alternative would be to use p-threads instead of concurrent processes since they share the same data-space and sophisticated locking mechanisms are already provided by p-threads. If you are looking for reader-writer locking functions (if they are not provided in your machine's implementation of p-threads), you can find my implementation of them in the unix programming archives at this site or from Richard W. Steven's UNIX Network Programming Vol II 2nd Edition.
Let me know if this is of any help
--Aditya.
You asked if your approach could be changed, here are a couple of suggestions below. I think the approach you are taking using pipes is not really practical. You are going to have two-way pipes to each and every child you fork which will make your program extremely complicated/messy (doing selects incrementally on socket and pipe file descriptors) and invariably impossible to maitain assuming that you are forking children to handle connections because you could have a number of concurrent connections (and associated child processes).
Why don't you use a blob of shared memory instead ? You need to take a guess at how big you want this blob to be; You could use this blob as an array of structures as opposed to a linked list. The advantage of using shared memory is that you can have any process attach to this blob and use it as if it were local to it. You should now worry about locking/unlocking on this blob since concurrent processes would be updating it (which would be the case anyway).
This is a typical problem of synchronization in a shared environment since the very reason you need a seperate process to handle each connection is that there could be multiple concurrent connections and any number of children could want to modify the list at any given time. Before you take on a job of this sort, you DO need to have an understanding of UNIX IPC.
A very much better alternative would be to use p-threads instead of concurrent processes since they share the same data-space and sophisticated locking mechanisms are already provided by p-threads. If you are looking for reader-writer locking functions (if they are not provided in your machine's implementation of p-threads), you can find my implementation of them in the unix programming archives at this site or from Richard W. Steven's UNIX Network Programming Vol II 2nd Edition.
Let me know if this is of any help
--Aditya.
ASKER
How would the parent know that the child has finished processing and is ready to send the linked list accross?
Would I have to use some for of IPC?
Thanks for your help
Chris.