Declined Interruption of commands

May 20, 2008
3,515
4
Elkridge, MD, USA
When a command is terminated by interruption, e.g., ctrl-C, it may have already generated thousands of lines of yet to be displayed output sitting in buffers. These buffers should be cleared without displaying their contents. After all, had the user wish to see them he would not have interrupted the command.
--
Steve
 

rconn

Administrator
Staff member
May 14, 2008
12,557
167
> When a command is terminated by interruption, e.g., ctrl-C, it may
> have already generated thousands of lines of yet to be displayed
> output sitting in buffers. These buffers should be cleared without
> displaying their contents. After all, had the user wish to see them
> he would not have interrupted the command.

That's not a TCC issue -- there *are* no buffers in TCC, and a ^C will
immediately terminate output without displaying any additional data.

However, TCC cannot control what a plugin or external app is going to do
when they trap a ^C.
 
May 20, 2008
3,515
4
Elkridge, MD, USA
From: rconn
| That's not a TCC issue -- there *are* no buffers in TCC, and a ^C will
| immediately terminate output without displaying any additional data.
|
| However, TCC cannot control what a plugin or external app is going to do
| when they trap a ^C.

Thanks for the clarification.
--
Steve
 
May 20, 2008
12,175
133
Syracuse, NY, USA
On Thu, 27 Oct 2011 08:56:22 -0400, rconn <> wrote:

|That's not a TCC issue -- there *are* no buffers in TCC, and a ^C will
|immediately terminate output without displaying any additional data.
|
|However, TCC cannot control what a plugin or external app is going to do
|when they trap a ^C.

How does all this work? Are there buffers anywhere? Is program execution paced
by the console's ability to display output or can output accumulate somewhere
(before it appears in the console)?

And what **should** happen when a plugin command catches ^C and initiates its
own clean-up routines? If the Ctrl handler passes the signal to TCC is the
plugin function allowed to continue until it returns (having completed its
clean-up) or is there the possibility that it will be interrupted (and perhaps
not finish cleaning up)?
 

rconn

Administrator
Staff member
May 14, 2008
12,557
167
> How does all this work? Are there buffers anywhere?

There are buffers everywhere -- but not in TCC.


> Is program execution paced by the console's ability to
> display output or can output accumulate somewhere
> (before it appears in the console)?

That's up to the individual programs. Some buffer (i.e., with something
like fputs / fwrite / fprintf), and some don't. Some flush their buffers
when exiting, some don't.


> And what **should** happen when a plugin command catches ^C
> and initiates its own clean-up routines?

There is no standard. Some programs eat it and continue as though nothing
happened. Some die instantly; some meander on for a while and eventually
shut down.


> If the Ctrl handler passes the signal to TCC is the plugin
> function allowed to continue until it returns (having
> completed its clean-up) or is there the possibility that
> it will be interrupted (and perhaps not finish cleaning up)?

The exception is happening in a different thread, with a (very) limited
stack. You shouldn't be trying to do something very complicated, or you'll
likely blow the stack. (This is Windows, not TCC.)

All TCC does in its exception handler is set a flag that a ^C / ^Break
occurred. TCC then periodically checks for that flag when it's looping in
potentially long-running code.
 
May 20, 2008
3,515
4
Elkridge, MD, USA
From: rconn
| All TCC does in its exception handler is set a flag that a ^C / ^Break
| occurred. TCC then periodically checks for that flag when it's looping in
| potentially long-running code.

IIRC there has been an issue in the past about long delays between the break and its recognition when FTP operations are involved. Has your vendor improved this?
--
Steve
 

rconn

Administrator
Staff member
May 14, 2008
12,557
167
> IIRC there has been an issue in the past about long delays between the
> break and its recognition when FTP operations are involved. Has your
> vendor improved this?

There's nothing that TCC can do when it's waiting on a Windows or
third-party API.

Just as with your recent COPY question, if you use the /G option then TCC
gets notifications and can break out of the API call.
 
May 20, 2008
3,515
4
Elkridge, MD, USA
From: rconn
| Just as with your recent COPY question, if you use the /G option then TCC
| gets notifications and can break out of the API call.

But it has no equivalent in DIR or PDIR... or am I shortsighted again?
--
Steve
 
May 20, 2008
3,515
4
Elkridge, MD, USA
From: rconn

|| But it has no equivalent in DIR or PDIR...
|
| Irrelevant, because TCC gets notifications from the ftp server as each
| filename is retrieved for DIR and PDIR . The only time you could get a
| significant wait time is if the server doesn't respond at all.

The server won't have anything with which to respond for a long time if you perform a wildcard search for a filename that does not exist. For example, if the server has a *nix file system, the command
dir /s ftp:/*.exe
is likely to have a long wait time. Since it is very likely the command was issued by mistake, the user may want to interrupt as soon as the mistake is recognized. Yet TCC would not have any response from the server that would allow recognizing command interruption. This kind of thing happens to me often, so I often try to interrupt fruitless FTP searches - but that cannot be done! this is the kind of situation when I would hope that TCC could send a "cancel" signal to the 3rd party software it uses for ftp: access, and that software would respond to the cancellation. On more than one occasion I ended up with a brute force cancellation by terminating TCC itself, usually by the TASKEND command from another instance of TCC (typically an earlier version kept around to deal with such special situations). Crude but functional...
--
Steve
 

rconn

Administrator
Staff member
May 14, 2008
12,557
167
> The server won't have anything with which to respond for a long time if
> you perform a wildcard search for a filename that does not exist. For
> example, if the server has a *nix file system, the command
> dir /s ftp:/*.exe
> is likely to have a long wait time.

Not really. It will be interrupted at every directory level, so unless you
have humongous individual directories, you might have to wait a maximum of a
second or two.

Within a single directory, we're at the mercy of the FTP protocol. Unless
you can convince the standards committee to change that ...
 
May 20, 2008
3,515
4
Elkridge, MD, USA
From: rconn
| Not really. It will be interrupted at every directory level, so unless you
| have humongous individual directories, you might have to wait a maximum of a
| second or two.

I'll try soon.

| Within a single directory, we're at the mercy of the FTP protocol. Unless
| you can convince the standards committee to change that ...

Oh well... I once tried to have a standard designed for relay-based electromechanical communications for something more suitable for the electronic age, through the committee member I worked with. His answer was: "we always did it this way".
--
Steve
 
May 20, 2008
12,175
133
Syracuse, NY, USA
Rex wrote

"All TCC does in its exception handler is set a flag that a ^C / ^Break
occurred. TCC then periodically checks for that flag when it's looping in
potentially long-running code."

My handler has boiled down to the same as yours. Is that flag in the aGlobals structure? If so, would you say where? Does it distinguish between ^C and ^BREAK?
 

rconn

Administrator
Staff member
May 14, 2008
12,557
167
> "All TCC does in its exception handler is set a flag that a ^C / ^Break
> occurred. TCC then periodically checks for that flag when it's looping in
> potentially long-running code."
>
> My handler has boiled down to the same as yours. Is that flag in the
> aGlobals structure?

Yes.


> If so, would you say where?

No, because it changes in every version (and sometimes in individual
builds).


> Does it distinguish between ^C and ^BREAK?

No.
 
May 20, 2008
12,175
133
Syracuse, NY, USA
Yeah, after a vague recollection,I found that we had this discussion in April.

Would you export it separately? I suppose that could be done with one line in a
DEF file and one elsewhere, neither of which would require maintenance.

On Fri, 28 Oct 2011 10:39:18 -0400, rconn <> wrote:

|---Quote---
|> "All TCC does in its exception handler is set a flag that a ^C / ^Break
|> occurred. TCC then periodically checks for that flag when it's looping in
|> potentially long-running code."
|>
|> My handler has boiled down to the same as yours. Is that flag in the
|> aGlobals structure?
|---End Quote---
|Yes.
|
|
|
|---Quote---
|> If so, would you say where?
|---End Quote---
|No, because it changes in every version (and sometimes in individual
|builds).
|
|
|
|---Quote---
|> Does it distinguish between ^C and ^BREAK?
|---End Quote---
|No.
 
May 20, 2008
12,175
133
Syracuse, NY, USA
On Fri, 28 Oct 2011 10:57:10 -0400, vefatica <> wrote:

|Yeah, after a vague recollection,I found that we had this discussion in April.
|
|Would you export it separately? I suppose that could be done with one line in a
|DEF file and one elsewhere, neither of which would require maintenance.

Never mind. It doesn't work well.

When, in my WHICHWIN plugin, I failed to set my own ctrl handler (which sets
bInterrupt) and used

#define bInterrupt (*(globals.TCCGlobals+44))

my function was truly interrupted ... not allowed to finish ... never reaching
some cleanup routines (i.e., not freeing some memory). I suppose that's a
necessary safety precaution against misbehaving plugins.

No complaints, but I wonder ... how do you do that, kill a function you've
called, not allowing it to finish?
 
May 20, 2008
12,175
133
Syracuse, NY, USA
On Fri, 28 Oct 2011 11:35:01 -0400, rconn <> wrote:

|---Quote---
|> Would you export it separately? I suppose that could be done with one
|> line in a DEF file and one elsewhere, neither of which would require
|> maintenance.
|---End Quote---
|I don't see how that would help -- you'd still have to relink with every
|version (and many random builds), and maintain multiple versions.

Not if I get the address of fBreak dynamically as I get the address of aGlobals
... right?

HMODULE hTCDLL = GetModuleHandle(L"takecmd.dll");
global.TCCGlobals = (LPBYTE) GetProcAddress(hTCDLL,
"?aGlobals@@3UGLOBAL_VARIABLES@@A");

But as I said in another very recent post (please respond to that) it doesn't
work well. Leaving TCC's ctrl handler in charge does not allow my plugin
function to finish (clean up) and return when I press ^C.
 

Similar threads