6

I'm not sure how to go about handling asynchronous tasks in a program I am writing and I'm hoping someone more experienced can at least point me in the right direction.

I'm running Angstrom Linux on an embedded ARM processor. My program controls several servos through exposed hardware PWM and a camera over PTP. Additionally it is socket daemon which takes commands from an arbitrary client (Android in this instance). The camera PTP is slow, and I don't want to wait around for it to finish its task because the rest of the program needs to be responsive.

I've tried threads, but any problems in the camera thread seems to kill the whole process. Ideally I want to send the camera off on its own to do its thing and when it is finished let the main function know. Is this an appropriate forking technique or have I implemented threading improperly?

Additionally, I would like to stay away from large secondary libraries to avoid any more cross compiling issues then I already have. Thanks in advance for any suggestions.

Improve this question
3
  • 2
    Why don't you run it in a new process? Then communicate over sockets?
    – user377628
    Commented Jun 12, 2012 at 0:27
  • I was using Advanced Linux Programming as my guide...it doesn't cover the clone() function. Seems the appropriate technique
    – Count Zero
    Commented Jun 12, 2012 at 0:48
  • Could be. Or it could be system(). Take a look at that too.
    – user377628
    Commented Jun 12, 2012 at 0:54

3 Answers 3

Reset to default
3

Your problem sounds like a classic case for multiple processes, communicating with inter-process communications (IPC) of some sort.

The camera should have its own process, and if that process dies, the main process should not have a problem. You could even have the init(8) process manage the camera process; that can automatically restart the process if it dies for any reason.

You could set up a named pipe permanently, and then the camera process could re-open it any time it restarts after failure.

Here is some documentation about 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 vs. sockets:

IPC performance: Named Pipe vs Socket

Improve this answer
2
  • That UNIX and Windows document is terribly misinformed about unix pipes. popen is not a system call, pipes are in no way guaranteed to be 2-way (linux pipes aren't) and mknod is for special files, not just pipes as this document misleadingly claims.
    – Dave
    Commented Jun 12, 2012 at 1:35
  • Wow, that shows the perils of a quick Google search and quickly skimming a document. I apologize to everyone for posting a bad link. I'll edit that out of my answer right now.
    – steveha
    Commented Jun 12, 2012 at 1:46
1

Take the basic method of steveha's answer but skip the init(8) and named pipes.

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.

Improve this answer
3
  • The camera code works...my choice of words was poor. For example if no camera is connected then the camera thread returns and for whatever reason introduces a segmentation fault in the program. what is your opinion on the clone() function?
    – Count Zero
    Commented Jun 12, 2012 at 3:42
  • Clone is not going to do anything for you. Both threads and fork are just wrappers around clone. If you are having problems with them then dropping down a level lower isn't going to solve your problem. Perhaps you should post the basics of your thread code in another question. You might be making a very simple error.
    – Duck
    Commented Jun 12, 2012 at 4:35
  • Thanks everyone for their help. Used a fork with a simple pipe and things are working as I'd hoped. I like the idea of the signal handler to discover the state of the child process.
    – Count Zero
    Commented Jun 12, 2012 at 4:56
0

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.

Improve this answer
2
  • a return 0; introduces a segmentation fault
    – Count Zero
    Commented Jun 12, 2012 at 4:00
  • @CountZero: And what does gdb say is on the stack at the time? What line of code causes the seg fault?
    – Andrew Tomazos
    Commented Jun 12, 2012 at 4:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.