Hi all.
I'm developing an application on an embedded environement using an
ARM11 and Linux as OS.
This application must manage a camera that takes photos when the user
presses a hardware button and a display with a GUI.
Because I'm new to programming on a multithread OS (usually I write
software for micro-controllers), I'm wondering how to accomplish my
requirements.

If I were on a micro-controller, I would have a main process for the
display, and an interrupt routine that takes the photo, elaborates and
saves it, and updates some global variables (like the total number of
shots that can be displayed by the GUI), because this event is
asynchronous.
What I imagine now, is a main thread that manages the GUI, and a
thread that manages the camera only when needed, as a "quiescent"
process that shares variables and resources with the main thread.

Is this a correct way of think about threads (like a sort of interrupt
routine)?

Or can be more useful use a fork (or even two separate programs)?

Thank you in advance.

Alessandro

On Jan 23, 6:27=A0am, Melcataclysm <melcatacl...@gmail.com> wrote:
> Hi all.
> I'm developing an application on an embedded environement using an
> ARM11 and Linux as OS.
> This application must manage a camera that takes photos when the user
> presses a hardware button and a display with a GUI.
> Because I'm new to programming on a multithread OS (usually I write
> software for micro-controllers), I'm wondering how to accomplish my
> requirements.
>
> If I were on a micro-controller, I would have a main process for the
> display, and an interrupt routine that takes the photo, elaborates and
> saves it, and updates some global variables (like the total number of
> shots that can be displayed by the GUI), because this event is
> asynchronous.
> What I imagine now, is a main thread that manages the GUI, and a
> thread that manages the camera only when needed, as a "quiescent"
> process that shares variables and resources with the main thread.
>
> Is this a correct way of think about threads (like a sort of interrupt
> routine)?
>
> Or can be more useful use a fork (or even two separate programs)?

Threads are lightweight processes, and can be used as interrupts
(usually in a callback manner).
I suspect your threading questions are best posted on
news:comp.programming.threads

Threads are a bit cheaper in terms of resources but they also have a
down-side.

If something goes terribly wrong in a thread it can bring down the
whole process.
If something goes wrong in a forked process, it brings down only that
process.

What you should do will depend upon the exact particulars of what you
want to accomplish.

Melcataclysm <melcataclysm@gmail.com> writes:

> What I imagine now, is a main thread that manages the GUI, and a
> thread that manages the camera only when needed, as a "quiescent"
> process that shares variables and resources with the main thread.

It sounds plausible, but it doesn't seem to me like the `hardware
button' which requests the camera to take a picture is particularly
different from the events which drive the GUI.

I suppose a lot of things depend on how your process learns of the
button press.  If there's a device which usually blocks but becomes
readable when there's a button event waiting, for example, then you
should be able to plumb that into most GUI systems' main loops quite
effectively.  If it lets you know by sending a signal (that would be
weird) then you're probably best off either messing with signalfd(2)
(which is Linux specific, but handy) or the self-pipe trick: the signal
handler writes a byte to a pipe, and you select on the other end for
reading in the main loop.

> Is this a correct way of think about threads (like a sort of interrupt
> routine)?

The main difference is that the threads run concurrently.  An interrupt
routine tends to suspend the foreground program while it's executing,
and then resume it when it's finished.  In your example, the main GUI
will carry on running while you're taking a picture (and doing whatever
it is with the result).  This can be nice, because the user interface
doesn't freeze up, but it gives you an exciting collection of new
synchronization problems to deal with.

I fear threading in general.  If you really don't want the GUI to
freeze, and I can see why you wouldn't, then forking might be better:
receive button press, fork child, have the child take the picture and do
whatever it is, and then notify the parent of the outcome through a pipe
or something.

-- [mdw]

Melcataclysm wrote:
> Hi all.
> I'm developing an application on an embedded environement using an
> ARM11 and Linux as OS.
> This application must manage a camera that takes photos when the user
> presses a hardware button and a display with a GUI.
> Because I'm new to programming on a multithread OS (usually I write
> software for micro-controllers), I'm wondering how to accomplish my
> requirements.
> 
> If I were on a micro-controller, I would have a main process for the
> display, and an interrupt routine that takes the photo, elaborates and
> saves it, and updates some global variables (like the total number of
> shots that can be displayed by the GUI), because this event is
> asynchronous.

Asynchronous to what?  I don't have a lot of experience with multiple 
threads/tasks, but I first ask what functions need to happen 
concurrently to help partition the program.

Here is an outline for a single thread process for your program:

Initialize hardware
Initialize display
do forever
   Wait for capture button press
   take picture
   save picture
   display picture

That might not be sufficient for your requirements.  If not, why not?

-- 
Thad

> Asynchronous to what? =A0I don't have a lot of experience with multiple
> threads/tasks, but I first ask what functions need to happen
> concurrently to help partition the program.

Asynchronous to the main process.

>
> Initialize hardware
> Initialize display
> do forever
> =A0 =A0Wait for capture button press
> =A0 =A0take picture
> =A0 =A0save picture
> =A0 =A0display picture
>
> That might not be sufficient for your requirements. =A0If not, why not?
>

This is not only a take-snapshot/viewer program, but a program that,
sometimes and without user input, takes photos.
Then the user, if he/she wants can view how many and what photos was
taken.