Bug: ExitThread after dispay each directory entry

[Isica]

8.51a x86
When reading and rereading (Ctrl + R) directories, thread terminates after EACH file, and then re-created:

Code: Select all

CreateThread
Display(DirEntry1)
ExitThread
CreateThread
Display(DirEntry2)
ExitThread
...
CreateThread
Display(DirEntryN)
ExitThread

On slower machines, it significantly slows down the rendering of panels (and consumes extra resources).

In TC7.55 it was done properly:

Code: Select all

CreateThread
Display(DirEntry1)
Display(DirEntry2)
...
Display(DirEntryN)
ExitThread

[Dalai]

I don't think that's a bug. Search the history.txt for the term "thread" and you will see that TC does a lot more in a background thread (e.g. loading icons) to avoid blocking the main window or slowing it down, and to allow the operation to be aborted etc.

However, I don't know if TC is really supposed to create a new thread for each file... Are you using a custom columns view?

Regards
Dalai

[Isica]

However, I don't know if TC is really supposed to create a new thread for each file... Are you using a custom columns view

Yes, the thread terminates after displaying each file (each element of the directory).
Type of panels does not matter: the problem occurs even in standard modes 'Brief' and 'Full'.

In version 7.55, this problem is absent.

[milo1012]

On slower machines, it significantly slows down the rendering of panels (and consumes extra resources).

Any real proof or experience with that?
I use TC on an old P5 machine, and didn't encounter any speed loss when updating to 8.x.
Yes, CreateThread() has some overhead, but it's not as bad as you might think, I have my share of experience with it.
You sometimes have no other choice but to terminate an old thread and creating a new one.

In TC7.55 it was done properly

There is no "proper" way.
As Dalai said, look at the history.txt file.
There were a lot of reasons why especially icon extraction is now done in a BG thread.
Anyway, you took a program like Process Monitor, looked into what TC is actually doing,
and now think what is done is just wrong ?
I'd call it "improvement" if buggy behavior is fixed at the cost of a tiny overhead.

From what I can see it is related to overlay icons, i.e. when enabling them in Configuration -> Icons
you will get extra threads.
So it might or might not be related to this thread.
But still, I don't think it is wrong per se.

[Isica]

2milo1012
In my first post, I described the algorithm of TC8.51 and TC7.55.
Please note that the v7.55 also fills the panel a separate thread, but does not terminate it after each file!
So, IMHO, it is still a bug

[milo1012]

Please note that the v7.55 also fills the panel a separate thread, but does not terminate it after each file!

I understood what you described.
But I just explained why a different behavior, in that case terminating a thread, isn't a bug just because you say so.
It still does what it is intended for.

Anyway, only Christian can answer this.

[Lefteous]

2Isica
Can you tell us how you found out how the algorithm works? I'm pretty sure the dir listing itself is a single thread while displaying icons and other stuff is another story.

[Isica]

2Lefteous
And you just run the program under a debugger (eg, OllyDbg), and then look in his log. And see how many threads are created, and in what sequence.
And then run version 7.55, and feel the difference

[Lefteous]

2Isica
Thanks for the hint to OllyDbg. I have tried of such programs and could never really find out what exactly happens. Especially that you found that "Display(DirEntry1)" is what happens between to thread creations is astounding.

[milo1012]

Especially that you found that "Display(DirEntry1)" is what happens between to thread creations is astounding.

Erm...this is neither a "secret" nor is any debugger required for this.
Just use Process Monitor and you can see with overlay icons enabled:

Code: Select all

TOTALCMD.EXE    9456    Thread Create
TOTALCMD.EXE    9456    CreateFile    C:\DIR1
TOTALCMD.EXE    9456    FileSystemControl    C:\DIR1
TOTALCMD.EXE    9456    QueryDirectory    C:\DIR1\file1.txt
TOTALCMD.EXE    9456    CloseFile    C:\DIR1
TOTALCMD.EXE    9456    Thread Exit
TOTALCMD.EXE    9456    Thread Create
TOTALCMD.EXE    9456    CreateFile    C:\DIR1
TOTALCMD.EXE    9456    FileSystemControl    C:\DIR1
TOTALCMD.EXE    9456    QueryDirectory    C:\DIR1\file2.txt
...

With overlay icons disabled:

Code: Select all

TOTALCMD.EXE    9456    CreateFile    C:\DIR1
TOTALCMD.EXE    9456    QueryDirectory    C:\DIR1\file1.txt
TOTALCMD.EXE    9456    CloseFile    C:\DIR1
...

It's quite clear what's going on there.
TC is enumerating all files in a DIR when you enter it or refresh.

[Lefteous]

2milo1012
The thread starter claimed that there is one thread for just displaying every directory item which doesn't seem to be right. See my first post in this thread.

On monitoring: So what exactly is FileSystemControl?
The problem about this kind of monitoring is that they display basic API calls which is not what the program does but what the APi calls are doing internally.

[milo1012]

The thread starter claimed that there is one thread for just displaying every directory item which doesn't seem to be right. See my first post in this thread.

Am I talking to a wall here?
I now said twice and showed once what the OP meant.
He described it exactly as I just showed it.
When you use Process monitor you can clearly see that the ONLY place where threads
are created in a short time is the one that I showed in my last post.
It just doesn't matter WHAT exactly TC does in this thread (display, enumerating), the problem is the thread creation itself (according to Isica).
(I doubt that you can clearly confirm in the debugger that TC is just "displaying" the file because of the thread)

2Isica
Can you confirm that no threads are created when you disable overlay icons?

The problem about this kind of monitoring is that they display basic API calls which is not what the program does but what the APi calls

It shows what API functions the process calls.
And as we all know TC is using direct API calls most of the time.
I don't see the problem with that.
Just try it with your own programs and you can see that it monitors things all right.

[Lefteous]

2milo1012
Well you are not the thread starter and you just claim the same (regarding icon extraction) as I did - so what is your point?

[milo1012]

2milo1012
Well you are not the thread starter and you just claim the same (regarding icon extraction) as I did - so what is your point?

Well, I tried to confirm a second time what the OP meant, and your answer seemed
like you thought that I just explained something completely different.

Again: let's wait what Christian says about this.

[Lefteous]

2milo1012

It shows what API functions the process calls.
And as we all know TC is using direct API calls most of the time.
I don't see the problem with that.
Just try it with your own programs and you can see that it monitors things all right.

So just point me to the 'API call' of 'FileSystemControl' or 'Display(DirEntry1)'! My experience with these monitoring programs is that they display mostly low level garbage.