How to catch a user interruption?

[spibou]

Dear all,

Some background first:
I have a gtk window where my user pushes some
buttons with a definite pleasure. It usually
amounts to asking the program to try all possible
permutations which can take a long time... and
in between my user wants to change some parameters,
or simply wants to stop. Regularly this programm
outputs some messages corresponding to its state.
So how to do this properly? I can add a button
with "Stop" written on it, but what will it do???
This signal is caught, ok, and then?
Should I use a global variable, a USER_INTERRUPTION
that my Stop-button would put to true and check
regularly for its value?
Any comments on how this is usually and properly done
are most welcomed!! Or sample code, or pointers.

I have been wondering about a similar thing myself. The
only answer I could come up with was pretty much what
you're suggesting ie modifying a global variable and have
the part of the programme which performs the calculations
check regularly about the value of the variable. The tricky
part is to arrange things so that the programme checks often
enough as to not appear to be unresponsive but not so often
that it significantly slows down the calculations.

I haven't actually written any code which does this but pretty
much every chess playing programme will have some such
functionality so you could try and read their code. Crafty for
example is open source and it allows the user to enter input
from the keyboard while it does its calculations. It does its job
pretty well so your answer is hidden in its code. But it's a big
programme so it might be tricky to find it.

Hopefully others will have a more straightforward reply.

Spiros Bousbouras

 

[Olivier]

Dear all,

Some background first:
I have a gtk window where my user pushes some
buttons with a definite pleasure. It usually
amounts to asking the program to try all possible
permutations which can take a long time... and
in between my user wants to change some parameters,
or simply wants to stop. Regularly this programm
outputs some messages corresponding to its state.
So how to do this properly? I can add a button
with "Stop" written on it, but what will it do???
This signal is caught, ok, and then?
Should I use a global variable, a USER_INTERRUPTION
that my Stop-button would put to true and check
regularly for its value?
Any comments on how this is usually and properly done
are most welcomed!! Or sample code, or pointers.
Many thanks,
Amities,
Olivier

 

[Olivier]

(e-mail address removed) a écrit :

[...] it allows the user to enter input
from the keyboard while it does its calculations.

Ok, that's a good additionnal idea.
I'll settle for a global variable.
A.O.

 

[Flash Gordon]

(e-mail address removed) a écrit :

[...] it allows the user to enter input
from the keyboard while it does its calculations.

Ok, that's a good additionnal idea.
I'll settle for a global variable.
A.O.

Since this is really about how it is best to do things in GTK and
nothing to do with C itself you would both be best discussing this on
one of the GTK mailing lists. There you will have access to people who
are expert at programming with GTK and maybe even input from the
developers. So you are far more likely to get good advice from there
than from here where we discus C rather than all the myriads of third
party libraries you can call from C.

You may find it useful to read http://clc-wiki.net/wiki/intro_to_clc to
find out some of the regulars ideas about the purpose of the group.

 

[Olivier]

Flash Gordon a écrit :
[...]

Since this is really about how it is best to do things in GTK

[...]

Well, I wondered ... The signal handling is gtk stuff ok.
But the way to do that inside is way out of gtk to me.
Seems more like my dear and lost catch/throw mecanism
or exception stuff. I set the background with gtk to be
clear but that could have been anything, even a shell
thing. I agree that it has to do with inputs and outputs
of a program -- but many programs do have both, even
in C, no ?
A.O.

 

[Flash Gordon]

Flash Gordon a écrit :
[...]

Since this is really about how it is best to do things in GTK

[...]

Well, I wondered ... The signal handling is gtk stuff ok.
But the way to do that inside is way out of gtk to me.
Seems more like my dear and lost catch/throw mecanism
or exception stuff. I set the background with gtk to be
clear but that could have been anything, even a shell
thing. I agree that it has to do with inputs and outputs
of a program -- but many programs do have both, even
in C, no ?

C had no exception handling. The only mechanisms it has for your program
to detect some asynchronous external event are either if the event
causes a signal which you catch with a signal handler, you could then
set a flag (of type volatile sig_atomic_t) which you could regularly
test in you long running calculation, or you regularly polling to see if
the external condition is true. Neither method is very good for handling
this king of thing. There may, on the other hand, be a good way with
GTK, for example using two threads (which C knows nothing about) one for
the user interaction and one for the long running process. The GTK
people will know whether this or some other solution works best with GTK
(I know that on one Delphi application separate threads for user
interface and high speed serial comms worked well) but we won't here.
I'm only suggesting where you are likely to get the best advice for what
is a very common problem for people writing GUI based applications.

By the way, if you are executing code asynchronously (i.e. handling GUI
events) using any other mechanism that standard C signals then the C
language does not tell you how to avoid synchronisation problems, e.g.
your main code being half way through reading a variable when the
asynchronous code writes to it thus causing you to read half of one
value and half of another, even volatile sig_atomic_t is not guaranteed
for that, only for C signals.

 

[Olivier]

Flash Gordon a écrit :
[...]

C had no exception handling. The only mechanisms it has for your program
to detect some asynchronous external event are either if the event
causes a signal which you catch with a signal handler, you could then
set a flag (of type volatile sig_atomic_t) which you could regularly
test in you long running calculation, or you regularly polling to see if
the external condition is true. Neither method is very good for handling
this king of thing. There may, on the other hand, be a good way with
GTK, for example using two threads (which C knows nothing about) one for
the user interaction and one for the long running process. The GTK
people will know whether this or some other solution works best with GTK
(I know that on one Delphi application separate threads for user
interface and high speed serial comms worked well) but we won't here.
I'm only suggesting where you are likely to get the best advice for what
is a very common problem for people writing GUI based applications.

That was first class information!! Thanks!!
A.O.

 

[spibou]

(e-mail address removed) a écrit :

[...] it allows the user to enter input
from the keyboard while it does its calculations.

Ok, that's a good additionnal idea.
I'll settle for a global variable.
A.O.

Since this is really about how it is best to do things in GTK and
nothing to do with C itself you would both be best discussing this on
one of the GTK mailing lists. There you will have access to people who
are expert at programming with GTK and maybe even input from the
developers. So you are far more likely to get good advice from there
than from here where we discus C rather than all the myriads of third
party libraries you can call from C.

You may find it useful to read http://clc-wiki.net/wiki/intro_to_clc to
find out some of the regulars ideas about the purpose of the group.

This thread and any other is "really" about what the posters
make of it. I understood the GTK reference to be just background
material and considered the central point of the thread to be the
following question:

Assume you have a programme which performs many
calculations. Upon receipt of a signal you want the programme
to receive some input from the user and then resume with
the calculations or perhaps start new calculations based on
the input. How can such a thing be implemented in standard
C ?

Even if the original poster considered a GTK solution to
be the central point of the thread that doesn't mean that
the discussion has to terminate right there for not being
topical. As long as the original , possibly not topical question,
inspires a topical one then the discussion can continue on
the topical question. My previous post in the thread did not
mention GTK at all , it concentrated on standard C so it was
perfectly appropriate for here.

Spiros Bousbouras

 

[Flash Gordon]

(e-mail address removed) a écrit :

[...] it allows the user to enter input
from the keyboard while it does its calculations.
Ok, that's a good additionnal idea.
I'll settle for a global variable.
A.O.

Since this is really about how it is best to do things in GTK and
nothing to do with C itself you would both be best discussing this on
one of the GTK mailing lists. There you will have access to people who
are expert at programming with GTK and maybe even input from the
developers. So you are far more likely to get good advice from there
than from here where we discus C rather than all the myriads of third
party libraries you can call from C.

You may find it useful to read http://clc-wiki.net/wiki/intro_to_clc to
find out some of the regulars ideas about the purpose of the group.

This thread and any other is "really" about what the posters
make of it. I understood the GTK reference to be just background
material and considered the central point of the thread to be the
following question:

Assume you have a programme which performs many
calculations. Upon receipt of a signal you want the programme
to receive some input from the user and then resume with
the calculations or perhaps start new calculations based on
the input. How can such a thing be implemented in standard
C ?

It can't. At least, not without you scattering checks throughout the C
code and there are often *far* better solutions. It also can't be done
unless it is a signal in C terms, and I would be somewhat surprised if
clicking a button in the GUI provided a C type signal.

Even if the original poster considered a GTK solution to
be the central point of the thread that doesn't mean that
the discussion has to terminate right there for not being
topical. As long as the original , possibly not topical question,
inspires a topical one then the discussion can continue on
the topical question. My previous post in the thread did not
mention GTK at all , it concentrated on standard C so it was
perfectly appropriate for here.

I can't remember your post, but I believe you when you say it was
topical. I've also not said that the OP should not have asked the
question. What I've said is that the OP is likely to get better advice
on a GTK mailing list. I've also explained why I believe better advice
will be obtained their. Do you have some objection to me suggesting
where better advice is likely to be obtained? All I am trying to do is
get the OP the best possible help in solving the problem and surely
there is nothing wrong with that.