I am having problems with the shmget function. The code compiles correctly, but I get the error "shmget: Invalid argument" when I execute it. I am compiling on a Sparcstation 20 running solaris 2.6 and using the sun workshop c compiler v4.2.
Does anyone have any idea why this is failing?

/*
* Now we put some things into the memory for the
* other process to read.
*/
s = shm;

for (c = 'a'; c <= 'z'; c++)
*s++ = c;
*s = NULL;

/*
* Finally, we wait until the other process
* changes the first character of our memory
* to '*', indicating that it has read what
* we put there.
*/
while (*shm != '*')
sleep(1);

exit(0);
}

06-18-2002

Salem

According to the manual page I'm reading

EINVAL
The size argument is less than the system-imposed minimum or greater than the system-imposed maximum.
EINVAL
A shared memory identifier exists for key but the size of the segment associated with it is less than size and size is not equal to 0.

First guess - you're asking for too little - read the docs to find out what the minimum is.

> while (*shm != '*')
> sleep(1);
You might want to make shm a volatile pointer, if you're expecting the outside world to change this value when you're not looking.

06-18-2002

shaik786

Type ipcs on the shell prompt and check if another form of IPC (semaphore, message queue or shared memory) with the same key (5678) exists. If it exists, remove it and execute your program again.

And your program works fine here, i'm using DIGITAL 4.0

06-19-2002

Monster

Can you create any shared memory using a private key?

Code:

shmid = shmget(IPC_PRIVATE , size, IPC_CREAT | 0660);

06-19-2002

clancyPC

Thank you all,
Your replies were all helpful. Changing the size value from 27 to 512, which according to my research is the size of a block of shared memory on a sun box, was the winner. I may have a play with different sizings to see if it will go smaller. Salem also suggested making the pointer a volatile one, which when I found out what volatile meant, is a very good idea and the example I am following should have used it. In the final program it will not be necessary because the other processes will have read only access to the memory area.
If I may I would like to also get your opinions on where I am going with this. I want to write a new process that will once a day read in a file consisting of two columns of numbers. The process will take the file and create an AVL tree in shared memory. This will be available 24x7. An existing process will then be amended to attach to this area on startup and do a lookup on the first number and pull back the second number.
What do you think?

06-19-2002

Salem

Sounds OK so far
The only real trouble is the daily replace one tree with another, where you'll need to be extra careful you don't remove the old tree whilst another process is using it.