Why is the Synchronize directories window modal?

[SanskritFritz]

Does anyone know the reason? Can it be changed?

[Hacker]

It was discussed somewhere, somewhen, don't remember the exact outcome, though.

Roman

[SanskritFritz]

Yeah, i also did a search, and i seem to remember it. But what was the result ???!

[Hacker]

Something like "the user might modify a file and the synchronize window would have to recompare the whole data if compare by content is checked" maybe?

Roman

[SanskritFritz]

Yeah i thought so, but windows being a multitasking environment, i can do whatever i want during sync anyway. I can even start another insance of TC (and i am forced to do so during sync ), and delete the whole tree i'm synchronising. This is my responsibility, i probably know what i am doing. So IMHO having this window modal is totally useless.

[ghisler(Author)]

No, the problem is that synchronize uses parts of the main program, like a currently open ftp connection or plugin, or packers which aren't thread-safe.

[SanskritFritz]

or packers which aren't thread-safe.

Shame on me, I knew that...
Still, this is the only (!) problem, which really annoys me in TC: the modal search and synchronise windows.

[CoMiKe]

Hi!

I've read many times here that packers aren't thread safe, but would it be solved if it were only allowed to launch one packing operation at a time?

Or it's just a matter that packers are not thread safe with other non-packing threads?

Excuse my poor knowledge...

[SanskritFritz]

Yes, there must be a solution. Maybe if ftp or packer plugins are involved, then the dialog should be modal, otherwise nonmodal. This shouldnt be so hard to implement?

[Lefteous]

2CoMiKe

I've read many times here that packers aren't thread safe, but would it be solved if it were only allowed to launch one packing operation at a time?

Or it's just a matter that packers are not thread safe with other non-packing threads?

I will try to explain the problem. Given that we have a "background search". A packer which is able to extract files of type xyz has a global variable abc. When performing an unpacking operation the variable is modified and read. Now there are (at least) two places where the plugin could be used: In normal file operations and the search. If the unpacking operations is called twice at the same time the variable abc will return invalid values because it's for example modifed by the search call and read by the normal file operation call...
The way to solve this problem is for example a so called critical section which allows multiple unpacking operations at the same time but allows to only one thread to read or write to abc at the same time. Another way is to avoid commonly used variables like abc. This is a plugin programmer task!


I see 3 solutions to introduce background search:

1) Disallow background search and search in archives at the the same time. Needs a lot of work but few work than other solutions. The benefit for the user is limited.

2) Allow background search and search in archives at the same time. The packer interface would have to be extended to inform TC about the thread safety of the plugin. The problem here is that setting this flag means TC has to trust the plugin that it isa really thread save.
This solution requires a bit more work than the first solution for the author and it requires some work for the plugin authors.

3) Move the search to an extra program. Moving a part of the program to an extra application means overhead. To limit this overhead a lot of program code must be moved to a library which is used by both applications.
In addition the search result must be passed to to the main programm. That requires inter process communication. The right TC instance must be targeted. What happens if the user has closed this instance. Many situations have to be tested.
The advantage of this solution is that plugin authors don't have to care about multithreading. It's a fact that a part TCs power is based on a many packer plugin instead of many internal packers. So maybe that is a good solution.
Of course it requires the most work of all solutions for the author.

All solution have pros and cons so it might be difficult to choose the right one.

[SanskritFritz]

The problem here is that setting this flag means TC has to trust the plugin that it isa really thread save.

TC hast to trust the plugin anyway, as with a plugin you can gloriously freeze the whole application. So again, this would be a good solution i think.

[leopoldus]

Given that we have a "background search". ... Now there are (at least) two places where the plugin could be used: In normal file operations and the search. If the unpacking operations is called twice at the same time the variable abc will return invalid values because it's for example modifed by the search call and read by the normal file operation call...

Many users (me as well) use as a workaround starting an additional session of TC to search, synchronize etc. there. Is there any difference between using those processes and using the same variables from one or from two different sessions of TC?

[djk]

That's true I'm also often forced to open a new session of TC during long lasting searching or synchronization so I also often thought what's the difference between two independent session and one multisession.

[Hacker]

what's the difference between two independent session and one multisession

Shared memory space.

Roman

[CoMiKe]

Thanks for your explanation, Lefteous!

Ok, so must I get the conclusion that current packers do multiple packing operations in the same thread?

Because if they were not in the same thread, each variable would belong to a different thread, and it couldn't be overwritten, huh?