Linux parallel processing

Question

I am not sure how to handle asynchronous tasks in the program that I am writing, and I hope that someone more experienced can at least point me in the right direction.

I am running Angstrom Linux on an embedded ARM processor. My program controls several servos through the open hardware PWM and the camera through PTP. It is also a socket daemon that accepts commands from an arbitrary client (Android in this case). The PTP camera is slow, and I do not want to wait until it finishes its task, because the rest of the program must be responsive.

I tried the threads, but any problems in the camera stream seem to kill the whole process. Ideally, I want to send the camera on my own to do my thing, and when it is ready, let the main function know. Is this a suitable branching technique or am I threading incorrectly?

In addition, I would like to stay away from large secondary libraries to avoid any cross-compilation problems than I already have. Thanks in advance for any suggestions.

Answer 1

Take the main steveha response method, but skip init (8) and the named pipes.

fork() child element that contains your camera’s code and communicates via regular channels or domain sockets. The signal handler code for SIGCHLD is in parent.If the child dies to interrogate the reasons why with the return code from wait() . If he died on his own, then clean him and restart; if it ends, usually do what is appropriate in this case. Communicate with your child through any IPC that you ultimately choose. This gives you more control over the child than init , and domain sockets or channels, in particular, will simplify the configuration and communication between the parent and the child than using the FIFO funky semantics.

Of course, if there are really problems with the camera code, all that you really did makes the errors more manageable without removing the entire program. Ideally, you should get a camera code in order to work flawlessly if it is in your power.

Answer 2

Your problem sounds like a classic case for several processes, interacting in some way with interprocess communication (IPC).

The camera must have its own process, and if this process dies, the main process should not have a problem. Perhaps even the init(8) process controls the camera process; which can automatically restart the process if it dies for any reason.

You can configure the named pipe on an ongoing basis, and then the camera process can reopen it anytime after a restart.

Here is some documentation on named pipes:

http://www.tldp.org/LDP/lpg/node15.html

I found this from the Wikipedia page:

http://en.wikipedia.org/wiki/Named_pipe

I searched StackOverflow and found a discussion of named pipes versus sockets:

IPC Performance: Named Pipe vs Socket

Answer 3

I tried the threads, but any problems in the camera stream seem to kill the whole process.

When you say that you are killing the whole process, what really happens?

I am telling you that you are better off debugging the above problem than trying to wrap the error in a forked process. You are better off having a reliable system, including a reliable camera, than a reliable kernel system with an unreliable camera.