|
From: | Riccardo Mottola |
Subject: | Re: GWorkspace file operation pause/stop problems |
Date: | Mon, 04 Aug 2014 00:16:07 +0200 |
User-agent: | Mozilla/5.0 (X11; FreeBSD i386; rv:9.0.1) Gecko/20120110 Firefox/9.0.1 SeaMonkey/2.6.1 |
Hallo Wolfgang, Wolfgang Lux wrote:
where do you think the thread is "closed"? I suppose when "endOperation" gets called. I understand it happens in "done" and "dealloc", but that path is taken only when the taks ends or stop is hit (in doCopy and doMove... why the other differ I'll check later on):I finally got around to upgrade my GNUstep tree and was able to reproduce your problem. Looking at the code, then, the problem is fairly obvious: When you click the pause button for the first time, the paused flag is set to YES and once the FileExecutorObject notices that the flag is set it exits the loop in do{Move,Copy,Link,Remove,Duplicate,Trash}. This also means that the secondary thread that was started to perform the operation in the FileOpExecutor +setPorts: will terminate and the executor object will be released and probably the connection to that object is closed as well. So it looks like the executor attribute in the FileOpInfo class is no longer connected to a valid object that could resume the file operation when you click the pause button again.
if (([files count] == 0) || stopped) { [self done]; }if stopped or paused are set as flags, the while loop gets a break, but "done" is called only on a proper quit/task completion.
Thus I understand that if "pause" is hit, the loop ends, the executor should stay around.
This makes the whole "stop" a bit quirky, but that is different. if what's your understanding of termination instead? Riccardo
[Prev in Thread] | Current Thread | [Next in Thread] |