question on event-generated errors (was Re: newbie TkCon question) 
Author Message
 question on event-generated errors (was Re: newbie TkCon question)

Thanks to Jeff Hobbs for help with signals and TkCon.  Now, however,
I'm having a more general problem related to the use of the "error"
command.  According to both the Ousterhout and Welch books, an
uncaught error should unwind the stack and abort script execution.
What I'm doing is sending SIGINT to a process on a <Control-c> event,
and I set an action using the trap subcommand of TclX's signal
command:

    signal trap SIGINT {error "SIGINT received"}
    bind TkConsole <Control-c> {
        kill SIGINT [pid]
    }

Now I run the following from the TkCon window:

    set i 0
    while {1} {
        puts $i
        update
        incr i
    }

<Control-c> events in the TkCon window do invoke my trap handler
(i.e. I get the standard bgerror dialog with my error message).  But
when I send the dialog away, the loop continues executing, instead of
aborting like I want it to.  Defining my own bgerror to explicitly
return non-zero (i.e. error?) values does not help.

The following does do what I expect:

    set i 0
    while {1} {
        puts $i
        if {$i > 100} { error "breaking out of loop" }
        incr i
    }

Clearly, I don't understand the relationship between events and the
procedural execution stack.  I suppose events are processed in a
separate thread?  Is this why my loop is not aborted?  Is there any
way that I can achieve the script abort behavior in response to an
event-generated error that I want?  Any advice is greatly
appreciated...

-Ken Wang

Quote:
> Jeff Hobbs:

> > Ken Wang:
> > how can I get signals in the TkCon window to get handled by the TclX
> > signal handler?

> The problem is really that Tk windows don't see signals like a
> regular xterm.  When you do a ^C in TkCon, it is just another char,
> or event binding that I can make.  In order to receive this in the
> manner you expect, you have to bind ^C to TkConsole like so:

>         bind TkConsole <Control-c> {
>                 kill SIGINT [pid]
>         }

> The kill comes from TclX as well, and sends our process the SIGINT
> signal as you really wanted it.

--

------------------------------------------------------------------------

Electrical Engineering Dept.    Voice:  (650) 725-0458
Stanford University             Fax:    (650) 725-7731
CIS 214, Stanford, CA 94305     Web:     http://www.*-*-*.com/ ~kenwang
------------------------------------------------------------------------



Sat, 10 Nov 2001 03:00:00 GMT  
 question on event-generated errors (was Re: newbie TkCon question)

Quote:

> command.  According to both the Ousterhout and Welch books, an
> uncaught error should unwind the stack and abort script execution.
> What I'm doing is sending SIGINT to a process on a <Control-c> event,
> and I set an action using the trap subcommand of TclX's signal
        ...
> Now I run the following from the TkCon window:
>     while {1} {
>         puts $i
>         update
>         incr i
>     }
> <Control-c> events in the TkCon window do invoke my trap handler
> (i.e. I get the standard bgerror dialog with my error message).  But
> when I send the dialog away, the loop continues executing, instead of
> aborting like I want it to.  Defining my own bgerror to explicitly
> return non-zero (i.e. error?) values does not help.
        ....
> Clearly, I don't understand the relationship between events and the
> procedural execution stack.  I suppose events are processed in a
> separate thread?  Is this why my loop is not aborted?  Is there any

Oh yes, of course this gets a lot more complicated with an event
model.  Basically, it isn't threading, but it does allow interrupt
handling since you put the "update" in.  Actually, if you left out
the update, you might never receive the signal since tkcon would
just be concerned with the while loop.  If you put the ^C in the
xterm where tkcon originated, then you are guaranteed that Tcl gets
it sometime.

With the "update", the while is interrupted, the ^C trap is evaluated,
and then the while continues.  In fact, with the "update" in there,
you can still basically continue to use tkcon in full, outside of the
fact that it will be spitting numbers out as fast as possible to stdout
(tkcon's stdout, that is).  What you need instead is some sort of
break functionality.  Either:
        while {!$::DONE} { ....
or replace "update" with "cond_update" that is something like:
        proc cond_update {args} {
                uplevel 1 update $args
                if {[magic_flag_was_set]} { return -code error "Break Out" }
        }

You could actually do this without the use of TclX signals at all, but
you have to make sure to have the update in there.  A bit tricky, but
in the event-based world, you have to view it from the sources.


**  I'm really just a Tcl-bot    My opinions are MY opinions  **

  Jeffrey.Hobbs.vcf
< 1K Download


Sun, 11 Nov 2001 03:00:00 GMT  
 question on event-generated errors (was Re: newbie TkCon question)

 > Thanks to Jeff Hobbs for help with signals and TkCon.  Now, however,
 > I'm having a more general problem related to the use of the "error"
 > command.  According to both the Ousterhout and Welch books, an
 > uncaught error should unwind the stack and abort script execution.
 > What I'm doing is sending SIGINT to a process on a <Control-c>
 > event, and I set an action using the trap subcommand of TclX's
 > signal command:

 >     signal trap SIGINT {error "SIGINT received"}
 >     bind TkConsole <Control-c> {
 >         kill SIGINT [pid]
 >     }

 > Now I run the following from the TkCon window:
 >
 >     set i 0
 >     while {1} {
 >         puts $i
 >         update
 >         incr i
 >     }

 > <Control-c> events in the TkCon window do invoke my trap handler
 > (i.e. I get the standard bgerror dialog with my error message).  But
 > when I send the dialog away, the loop continues executing, instead
 > of aborting like I want it to.  Defining my own bgerror to
 > explicitly return non-zero (i.e. error?) values does not help.

An event loop (or a single iteration of it like in 'update') basically
catches all errors generated by scripts called in response to
events. The catched information is used to display the standard
bgerror dialog, or whatever bgerror is defined to do. But at that
point the error is no such anymore. Because of this 'update' does not
return an error, and your while-loop continues.

 > Clearly, I don't understand the relationship between events and the
 > procedural execution stack.  I suppose events are processed in a
 > separate thread?

No, but you can see it as a separate execution stack which is build
and scrapped by all commands doing event processing (update,
vwait). Errors in this separate stack don't spill over into the
calling stack, but are handled by 'bgerror'.

--
Sincerely,

                        <http://www.westend.com/~kupries/>
-------------------------------------------------------------------------------



Sun, 11 Nov 2001 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. simple newbie question on sending keystrokes -- generate event

2. A silly tkCon question for Jeffrey Hobbs (or other tkCon user)

3. Newbie questions about TkCon

4. newbie TkCon question

5. Question about "event generate"

6. "event generate" question

7. Subject: Re: Newbie question (was Re: I am new)

8. Simple Newbie Question: What am I doing wrong?

9. Newbie, File generating question and mailing list problem..

10. Newbie question: How do I generate random numbers?

11. Newbie Question (Was: Newbie Question...)

12. Newbie Question: Forcing a menu enabling event?

 

 
Powered by phpBB® Forum Software