passing an array pointer between two processes?
#1
Posted 23 February 2007 - 07:15 AM
#2
Posted 23 February 2007 - 09:47 AM
#3
Posted 23 February 2007 - 10:15 AM
Personally I like sockets because it can then be extended across networks too.
But it sounds like you want shared memory. Named pipes seems like a good approach to this.
#4
Posted 23 February 2007 - 05:46 PM
#5
Posted 23 February 2007 - 07:11 PM
dave_ said:
Personally I like sockets because it can then be extended across networks too.
But it sounds like you want shared memory. Named pipes seems like a good approach to this.
Just by chance, how would you pass an array using sockets? I'm not that great at network programming and this is one of my challenges that I look forward to tackeling so that I can increase my skill. Any help would be appreciated.
#6
Posted 23 February 2007 - 10:18 PM
#7
Posted 24 February 2007 - 02:55 AM
#8
Posted 24 February 2007 - 03:49 AM
The idea behind this is that it's valid to pass the handle between processes. The kernel then maps the memory into the process address space. All processes that work with that handle will see the same physical memory.
#9
Posted 24 February 2007 - 04:46 AM
celu said:
No, because each process executes in its own virtual address space. Processes don't normally have access to each others' memory. However you can use GlobalAlloc as Nils suggested, or you can also use the memory-mapped I/O API, which does more or less the same thing.
#10
Posted 24 February 2007 - 07:21 PM
#11
Posted 24 February 2007 - 08:32 PM
#12
Posted 24 February 2007 - 10:13 PM
You almost got it. Global Memory handles are serialized. Only one process can lock it. So after process A has written some stuff it has to unlock the handle. Then process B can lock it and read/write the data.
You might see the same pointer in all processes. If so the kernel has allocated shared address-space for you (ain't that nice?). You can't however access the data without locking. Just locking once and remembering the pointer won't work.
If you have a pipe and you can send data, use it. I personally find global memory handles easier to deal with (I pass them around using window-messages or across dll boundaries). It's just a mater of preference though.
My stuff: torus.untergrund.net <-- some diy electronic stuff and more.
#13
Posted 24 February 2007 - 10:35 PM
-
Currently working on: the 3D engine for Tomb Raider.
#14
Posted 25 February 2007 - 04:10 PM
#15
Posted 25 February 2007 - 06:51 PM
#16
Posted 25 February 2007 - 11:35 PM
-
Currently working on: the 3D engine for Tomb Raider.
#17
Posted 26 February 2007 - 12:32 PM
#18
Posted 19 March 2007 - 05:24 PM
I have two processes A and B, A passes some data to B through named-pipe, (in reality it is passing a pointer to some data in A's memory space) so when B receives the data, it gets the correct value of the pointer, but the pointer which B received doesn't point to a memory location in A's memory space. (I know this because the data accessed by B's pointer received from A is not the same value assigned by A before passing the pointer)
Here are two points.
i) My understanding is that process A and B don't share the same memory space hence passing pointers to each other is fruitless so I need to set up shared memory between A&B (I need confirmation on this point)
ii) But looking at a driver code, this is exactly what is being done, when I need to read from a device, I pass a pointer to the location where I want the data from the device and the driver returns when it has written data in that location. The location where I want my data to be stored is of course in my memory space but the driver is stable able to access that space.
(so my understanding is that in (ii) it happens because the driver is under the kernel-control so kernel allows such things but two processes in user-space aren't allowed to do such things)
I have modified a small client-server model taken from ,
http://developers.su...d_pipes.html#2a
which proves one, but I need confirmation that what I have done is correct and what I have concluded is correct too.
Thanks
Server CODE:
#include <stdio.h>
#include <errno.h>
#include <ctype.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include "full_duplex.h" /* For name of the named-pipe */
int main(int argc, char *argv[])
{
int rdfd, wrfd, ret_val, count, numread;
char buf[MAX_BUF_SIZE];
unsigned long *buff;
int *buffPtr;
buff = (unsigned long *)buf;
ret_val = mkfifo(NP1, 0666);
if ((ret_val == -1) && (errno != EEXIST)) {
perror("Error creating the named pipe");
exit (1);
}
/* Open the first named pipe for reading */
rdfd = open(NP1, O_RDONLY);
/* Read from the first pipe */
numread = read(rdfd, buf, MAX_BUF_SIZE);
printf("Num Read %d %ld\n", numread, buff[0]);
buffPtr = (int *)buff[0];
printf("%ld\n", buffPtr);
printf("%d\n", *buffPtr);
}
Client CODE:
#include <stdio.h>
#include <errno.h>
#include <ctype.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include "full_duplex.h" /* For name of the named-pipe */
int main(int argc, char *argv[])
{
int wrfd, rdfd, numread, sample;
int *address;
char rdbuf[MAX_BUF_SIZE];
unsigned long *buff;
address = &sample;
sample = 33;
buff = (unsigned long *)rdbuf;
buff[0] = (unsigned long)&sample;
printf("%d %ld %ld\n", sample, &sample, buff[0]);
/* Open the first named pipe for writing */
wrfd = open(NP1, O_WRONLY);
/* Write to the pipe */
write(wrfd, rdbuf, 8);
exit(0);
}
#19
Posted 19 March 2007 - 05:27 PM
Now as for your question.
(i) Yes.
(ii) Yes.
#20
Posted 21 March 2007 - 10:42 PM
So in my client code I created any anonymous memory segment which was supposed to be shared, (i used mmap to create it) and then I passed to pointer to this memory the server, and the pointer value on the server side is the same as the client yet the data doesn't match.
i) In Stevens book (Unix Networking, IPC) the memory is shared across child and parent
ii) How can we share memory between two unrelated processes.
iii) Should I use System V IPC (shmget, shmid etc) compared to using BSD sharing (mmap)??
Thanks
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users












