Declined Interruption of commands

[Steve Fabian]

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]

> 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.

 

[Steve Fabian]

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

 

[vefatica]

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]

> 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.

 

[Steve Fabian]

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]

> 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.

 

[Steve Fabian]

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

 

[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.

 

[Steve Fabian]

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]

> 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 ...

 

[Steve Fabian]

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

 

[vefatica]

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]

> "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.

 

[vefatica]

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.

 

[rconn]

> 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.

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.

 

[vefatica]

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?

 

[vefatica]

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.

 

[rconn]

> No complaints, but I wonder ... how do you do that, kill a
> function you've called, not allowing it to finish?

TCC has an exception handler (__try / __except) wrapped around the plugin
function call.