Re: GWorkspace file operation pause/stop problems

[Riccardo Mottola]

Hi Wolfgang.

Thank you for the extensive explanation. I was missing the basic that 
the thread was spawned as a single method, once the method ended, 
"done"... tracing the whole chain is indeed long, there is even one step 
more.

It took me a while to reply, because I was on holiday and was actually 
thinking about a solution.

Wolfgang Lux wrote:
> Now turning to the +setPorts: method, it uses DO to call -registerExecutor: on 
> the FileOpInfo instance on the main thread. So the code in the auxiliary thread 
> now waits for the -registerExecutor: call on the main thread to finish and once 
> that happens the auxiliary thread will terminate.
>
> Next looking at the -registerExecutor: method, this uses DO again to call the 
> -calculateNumFiles method on the FileExecutor instance. This call is going to 
> be processed on the auxiliary thread while that thread is still waiting for the 
> -registerExecutor: method to finish on the main thread. Yet, since 
> -calculateNumFiles is (correctly!) declared as oneway method -registerExecutor: 
> will not wait for -calculateNumFiles to terminate and just return immediately. 
> So the main thread sends a reply back to the auxiliary thread which is still 
> executing the -calculateNumFiles method. But once -calculateNumFiles returns, 
> the DO call to -registerExecutor: on the auxiliary thread will return as well 
> and hence the auxiliary thread will terminate.
>
> So finally, we can look at -calculateNumFiles. At the end, this method calls 
> -performOperation and the latter calls one of the -do... methods, e.g., 
> -doMove. So if the loop in -doMove is exited, which happens once the paused 
> flag is set, the -doMove method, the -performOperation method and the 
> -calculateNumFiles methods all exit at once. And that means the 
> -registerExecutor: can return its result and terminate the auxiliary thread.
I would see two basic ways of fixing it:
1) when "paused" the thread shouldn't quit but loop and wait for a 
resume, that way the status is preserved
2) The caller preserves all the necessary status and on resume re-spawns 
the operation thread where it previously left off.

Essentially, "FileOpInfo" calls FileOpExec, both maintain an array of 
files to process, the latter also having and array of processed files.

I preferred 2) and proceeded as follows:
a) I split the startOperation method in two: the user-intraction part 
remains in startOperation, the latter part in "detachOperationThread"
b) after doCopy, if there are files left an it is not stopped in 
FileOpExec calls FileOpInfo's removeProcessedFile which asks FileOpExec 
for the processed file and removes them. It is a bit convoluted because 
one is an array of string,, the other of dictionaries and the passing 
happens through an archived NSData.... I though thread shared memory, 
but processedFiles was already done so.
c) a subsequent "resume" after pause just calls detachOperationThread: 
the operation did not chance, the files to process are the remaining and 
a new thread gets detached without user panel.

What do you think of this?
Sadly, it only partially works: processing continues and the remaining 
files get copied successfully! Using "top" I see that the ancillary 
thread gets spawned again. However, GWorkspace remains unresponsive, one 
cannot click, do anything. I wonder why? GWorkspace can be now "killed" 
with a crl-c, there are no running processes anymore.


I also have a concern: if a user "skips" a file for some reason (e.g. 
during copy only older files get copied), does it result processed? I 
fear that it could happen that they get reprocessed.

Perhaps instead of a single remove method, a continuous syncing after 
each file would be safer? Why do  I need a copy at all actually, can't a 
thread access directly the other class? It has shared memory and here DO 
is used only locally.

Riccardo

gw-op.patch
Description: Text Data