> > Screen savers don't generally block other applications. What leads you
> > to believe that your app "goes to sleep?" Is it possibly just running
[quoted text clipped - 9 lines]
> while. It's odd I had similar problems with network reliant software
> on an iBook sometime ago.
> In article
> <94273c32-3db2-4a5f-8741-4f14a332acd0@h11g2000prf.googlegroups.com>,
[quoted text clipped - 17 lines]
> either be running in a separate thread, or use the 10.5 only calls to
> specify which runloop modes are OK for it.
Can you expand on that, or provide a pointer to more detail? I wasn't
aware that the screen saver invoking would trigger a change in the run
loop mode of other apps and haven't so far found details or even
confirmation via Google.
rodmc - 12 Mar 2008 22:24 GMT
> Can you expand on that, or provide a pointer to more detail? I wasn't
> aware that the screen saver invoking would trigger a change in the run
> loop mode of other apps and haven't so far found details or even
> confirmation via Google.
Thanks to both of you for answering my initial question. Will this
also apply in a Python app?
best,
rod
Gregory Weston - 13 Mar 2008 09:17 GMT
In article
<9520868e-f28f-4bd3-b440-acc8fdbe41bd@e25g2000prg.googlegroups.com>,
> > Can you expand on that, or provide a pointer to more detail? I wasn't
> > aware that the screen saver invoking would trigger a change in the run
[quoted text clipped - 3 lines]
> Thanks to both of you for answering my initial question. Will this
> also apply in a Python app?
Unless the interpreter goes out of its way to notice that
ScreenSaverEngine is running and modify its behavior on its own, yes. A
process is a process. The language doesn't really change anything
fundamental about how it interacts with other processes.
rodmc - 19 Mar 2008 13:05 GMT
> In article
> <9520868e-f28f-4bd3-b440-acc8fdbe4...@e25g2000prg.googlegroups.com>,
[quoted text clipped - 11 lines]
> process is a process. The language doesn't really change anything
> fundamental about how it interacts with other processes.
Fair point, and thanks for your help. I actually managed to trace what
I think is the problem to the use of the Python OS module, in
particular commands to move, copy or remove files. When run outside a
threading environment they are ok, however the minute they are inside
a thread things seem to go wrong - even when a lock is applied.
Rod
David Phillip Oster - 13 Mar 2008 02:51 GMT
> > NSURLConnection by default is only registered in the default runloop
> > mode. If you want it to run when a screen saver is up, you need to
[quoted text clipped - 5 lines]
> loop mode of other apps and haven't so far found details or even
> confirmation via Google.
Yes: I was wrong about screensavers having any effect. I wrote a Cocoa
test program:
@implementation AppDelegate
- (void)awakeFromNib {
[[NSTimer scheduledTimerWithTimeInterval:1. target:self
selector:@selector(fired:) userInfo:nil repeats:YES] retain];
}
- (void)fired:(NSTimer *)timer {
NSLog(@"%@", [NSDate date]);
}
@end
Ran it, put up a screen saver, typed my username/password into the auth
dialog box to clear the screen saver, and checked the log.
No calls to NSLog were dropped. The presence or absence of a screen
saver does NOT affect the default run loop mode of the front application.
But, the test program will block the timer if you hold down the mouse
button while the mouse cursor is in the app's menu bar.
And, NSURLConnection will similarly pause, unless you use the new 10.5
calls to affect its runloop mode.