我不确定如何在我正在编写的程序中处理异步任务，我希望更有经验的人至少可以为我指明正确的方向。
我在嵌入式 ARM 处理器上运行 Angstrom Linux。我的程序通过暴露的硬件 PWM 和 PTP 上的摄像头控制多个伺服系统。此外，它是从任意客户端（在本例中为 Android）获取命令的套接字守护程序。相机 PTP 很慢，我不想等待它完成任务，因为程序的其余部分需要响应。
我尝试过线程，但相机线程中的任何问题似乎都会杀死整个过程。理想情况下，我想自己送相机去做它的事情，当它完成时让主要功能知道。这是一种适当的分叉技术还是我不正确地实现了线程？
此外，我想远离大型二级库，以避免出现更多交叉编译问题。在此先感谢您的任何建议。
您的问题听起来像是多进程的经典案例，与某种进程间通信 (IPC) 进行通信。
相机应该有自己的进程，如果那个进程死了，主进程应该没有问题。你甚至可以让init(8)进程管理摄像头进程；如果它因任何原因死亡，它可以自动重新启动进程。
您可以永久设置命名管道，然后相机进程可以在失败后重新启动时重新打开它。
以下是有关命名管道的一些文档：
http://www.tldp.org/LDP/lpg/node15.html
我从维基百科页面找到了这个：
http://en.wikipedia.org/wiki/Named_pipe
我搜索了 StackOverflow，发现了关于命名管道与套接字的讨论：
采用 steveha 回答的基本方法，但跳过 init(8) 和命名管道。
fork() a child containing your camera code and communicate through regular pipes or domain sockets. Code a signal handler for SIGCHLD in the parent.If the child dies interrogate the reasons why with the return code from wait(). If it died on its own then cleanup and restart it; if it ended normally do what is appropriate in that case. Communicate with the child through whichever IPC you end up choosing. This give you more control over the child than init and domain sockets or pipes, in particular, will make it easier to set up and communicate between parent and child than messing with the funky semantics of FIFOs.
Of course, if there is really problems with the camera code all you have really done is make the failures somewhat more manageable by not taking down the whole program. Ideally you should get the camera code to work flawlessly if that is within your power.
I've tried threads, but any problems in the camera thread seems to kill the whole process.
When you say kill the whole process, what actually happens?
I put it to you that you are better off debugging the above problem, than trying to wrap the bug away in a forked process. You would rather have a reliable system including a reliable camera, than a reliable core system with an unreliable camera.