Re: Question about cancelling sub-routine

[muppet <scott asofyet org>]

On Aug 12, 2010, at 11:07 PM, Mike Martin wrote:

> This works
>
> if ($append == 1){
>
> die (main::encode_loop) if $count == 100; # this is a count as a test
> - the loop goes from 1-150
> }
>
> but if I try to put it as the action for a cancel sub it fails silently
>
>
> $widget{btn_cancel}->signal_connect('clicked', sub {
>
> die (main::encode_loop)
>
>       );
>
> any suggestions


Need more context.  Is the loop you're trying to kill on the main thread, on a background thread, or a chain 
of idle events?  Does the btn_cancel callback run when clicked or wait to run until after the loop finishes?


As written, die() from a button callback is rather pointless.  That will cause the exception in the event 
handler, which will be caught and eaten (see old threads from '04 or so for why that is, and the faq [1] for 
some info on what it does).

If the encode_loop you're trying to cancel is on the main thread, then most likely the callback doesn't run 
until after the encode_loop completes, because that loop is blocking the main thread.  You'd need to do 
"Gtk2->main_iteration while Gtk2->events_pending" on each iteration of your encode_loop to handle events and 
possibly catch the cancel button event.  The event would have to set a flag that the encode_loop checks 
because of the aforementioned die()-eating behavior.

If the encode_loop is on another thread, you'll have to poke a thread-shared variable that your other thread 
reads, or otherwise forcibly kill the other thread.



[1]: 
http://live.gnome.org/GTK2-Perl/FrequentlyAskedQuestions#My_app_doesn.27t_die_when_there.27s_a_problem_in_a_signal_callback.2C_I_just_get_some_strange_error_message.2C_what.27s_up_with_that.3F

--
Aw, my lemon is empty.
  -- Yvonne, at dinner