working with processes

hi guys,i'm starting to work with processes and i'm finding some problems because the manpages and the documentations i'm studying with are not very clear (or better, i can't understand them very well :P ).i'm facing some problem with exec commands, in particular it says:

Code:

---

int execlp(char* file, char* arg1, char* arg2, ..... , char* argn, (char*) NULL)

---

For example i can make an execlp like:

Code:

---

execlp("ls", "ls" , "-l", NULL);

---

Then it says that file and arg1 often match, but i can't understand the difference. Digging a little around i made my idea that "file" is the name of the "ls" file in the path (for example, /bin/ls), while arg1 "ls" is the name of the process created by ls code.For example, i can make code that creates a process called "process1", and save that code in /bin/processgenerator. To invoke that code i should do:

Code:

---

execlp("processgenerator","process1", "randomarguments", NULL)

---

?----------------------Thank you very much :D

The "file" parameter is the actual file that you want to execute. It has to be able to be opened by the operating system, e.g. "/bin/ls". The arg1 in your prototype above corresponds to argv[0] in the program that you are calling. For example you could pass a short version of the filename such as "ls". I don't think there's a rule, but some programs like grep may decide on different modes of behaviour based on which name they are called with.

If in doubt, try the following program and see what the output looks like:

Code:

---

int main(int argc, char *argv[])
{
    for (int i = 0; i < argc; i++) {
        printf("arg %d: %s\n", i, argv[i]);
    }
    return 0;
}

---

For example, if I run this program from bash, I get the full path as argv[0]. If I run from a Windows command prompt, argv[0] corresponds to exactly how I typed the command, e.g. "printArgs" and "PrintArgs" and ".\printargs.exe" all refer to the same command in Windows, so in the case of this command interpreter, argv[0] tells the called program exactly what was typed.

Finally, if I call that program using execlp, then I get to decide for myself what appears as argv[0] to the program.

ok so it seems pretty similar to what i understood, right?btw, here's other questions, so check if i understood shared memory handling between processes.To ask for allocation of shared memory i use shmget, like:

Code:

---

int shmget (key_t key, int size, int flags)

---

Using this function i ask for shared memory depending of the key: if the key is IPC_PRIVATE, it creates a new segment (it can be used only by that process? by his children? if it can be used only by that process, it shouldn't be shared, so i think i didn't really understood this mechanism).By the way, once i created shared memory, it says i should attach my segment to an address:

Code:

---

shmat( int id, const void *id, int flags)

---

like this, passing as id the return of shmget, i should allocate my shared memory segment to a REAL address, is this right? or i didn't understand nothing?----------------------After all operations i need have been done, i should detach and eventually deallocate the memory.if i use shmdt i detach my process from the segment? my process has no more access to that memory?once all the process reading from the segment are terminated, i can deallocate the memory by using shmctl, right?last question, i read that a process, when using exec commands, involves the detach of all segments. it means that's as if i call shmdt for all the shared segments it's part of?

for future users facing this problem, i think i understood it:shmget actually allocates a shared memory slot of the size you want in the memory and returns an integer that identifies that segment, so you can retrieve it and link to it if you need.shmat actually "links" you to the shared memory segment, allowing you to correctly read and\or modify the content of the segment, depending on the permissions of the process.shmdt unlinks you from the memory segment, that obviously is not deallocated or deleted: it's not anymore "pointed" by the process that called the smhat before.now the question changed: in my program i need to create some process that make read or write in a shared memory segment. as it should be a concurrent procedure, my code has a critic section that can be reached by the use of semaphores: before the critic section it should decrease the competitive semaphore, after the section it should relase the semaphore. my test case should prove and show that the code is "fail proof": if a process fails, or gets killed during the critic section, it should not compromise the regular behaviour of the execution.my questions are: is the use of SEM_UNDO safe on semop call to be sure that, if the process abnormally dies, the semaphore values are restored to original state?how can i kill a process, even better being sure for it to be killed in his critical section or generally in a part of the code? i need it to test the behaviour of the code if the process abnormally terminates in various parts of the execution.thanks and sorry for the wall of text.