I know that my question perhaps sound's a bit confusing, but I wan't to stop the terminating of a Cocoa Mac Os X application. I don't know if there is an API to that. And I also don't know how to do that.
My idea was to call an NSAlert inside the applicationWillTerminate: method. But that doesn't stop the termination of the App.
Another possibility would be to use a while loop, which doesn't stop, but this isn't any good practice, because it uses a lot of CPU and doesn't add any possibility of keeping the rest of the app running.
Please give me an idea, how I could solve this problem.
Much times thanks. =D
Implement the application delegate method applicationShouldTerminate:. Return either NSTerminateCancel or NSTerminateLater. If you return NSTerminateLater then you should eventually call replyToApplicationShouldTerminate: with your final answer.
Related
I'm trying to use a coroutine function outside of the event loop. (In this case, I want to call a function in Django that could also be used inside the event loop too)
There doesn't seem to be a way to do this without making the calling function a coroutine.
I realize that Django is built to be blocking and a therefore incompatible with asyncio. Though I think that this question might help people who are making the transition or using legacy code.
For that matter, it might help to understand async programming and why it doesn't work with blocking code.
After a lot of research I think these solutions could be helpful:
Update your legacy code to use asyncio:
Yes i know that it can be hard and painful, but it might be the sanest choice. If you are wanting to use Django like I was... Well, you've got a lot of work to do to make Django async'd. I'm not sure it is possible, but I found at least one attempt: https://github.com/aaugustin/django-c10k-demo (Though, in a youtube video the author explained all the shortcomings of this).
use asyncio.async or asyncio.Task:
These items will enable you to run something async inside of blocking code, but the downfall here is that you will not be able to wait for them to finish without doing something ugly like a while loop that checks if the future has completed... ugh, but if you don't need the result, that might work for you.
About case #2: Blocking code should be at least wrapped with .run_in_executor.
In a jnlp application, we create a modal popup extends from javax.swing.JDialog, and call dispose() to hide the dialog whenever necessary. However, sometimes the final client get repainting problem. The dialog doesn't really disappear, and its parent window look messy. I couldn't reproduce, but it happen many times on final client PC. I guess there are 2 possible reasons:
There is a thread in our application update the cursor directly. However, I can't prove this thread is the root cause of the issue.
Periodically, we have another process highly use the CPU in a few seconds. I tried to load the CPU, but I couldn't reproduce the issue too.
Any advice for me in this case?
Thanks!
It looks the answer is in the question ;-)
Having a thread (not the EDT) updating the UI (the cursor in your case) may lead to this kind of problem.
Hence, ensure that your thread calls SwingUtilities.invokeLater() (or invokeAndWait() depending on your needs).
Another possibility (but this depends a lot on what your thread does, without further description from your side, it is hard to tell) would be to use SwingWorker instead of a thread.
Is anyone aware of a way to receive NSURLDownload's delegate methods on a separate thread, i.e. not the main one? I am using an NSOperationQueue to manage them but at the moment I need to use the performSelectorOnMainThread method to get it too work. The problem with this is that it drives the kernel task crazy reaching about 30% of CPU cycles. Curiously this has only happened since upgrading to SL, when NSOperationQueue changed behaviour (not that I am dissing it, GCD rocks!)
Thanks
Colin
My first question is, what are you using NSURLDownload to do? Are you just downloading a bunch of files to the disk, or do you really want the data in memory?
If you're downloading a bunch of files to the disk and you don't want to do any special processing, I'd first try just firing off all the NSURLDownloads on the main thread, without bothering with an NSOperationQueue... I mean, how many operations are we talking about? Can they all run concurrently? The callbacks on the main thread shouldn't be too much of a problem, unless you are doing something heavyweight when you get notified you got some data, in which case it seems like...
Otherwise, I'd switch to using NSURLConnection. It's specifically documented to call you back on the thread you set it up on, and is more flexible. Of course, it's not as high-level, so if you really want files saved to disk, you're going to have to write the I/O yourself. Shouldn't be a huge hardship - it's like four extra lines of code.
-W
NSOperationQueue changed behaviour because it was buggy. It's seems really solid now but yeah, it has a different personality.
Reference (http://www.mikeash.com/?page=pyblog/dont-use-nsoperationqueue.html)
Can you give more info on your problem? Do you only need to notify when the download is finished? Are you doing many downloads at once?
I am developing a multi-threaded application in Cocoa. The main thread takes values from the user, and when a button is clicked I invoke a secondary thread in which a long calculation takes place. Now from this thread I have to return the output of every step of the calculation to the main thread. I want to periodically send data from one thread to the other. I can't find any simple example that does this. Any ideas?
There are a number of ways to do this, in rough order of complexity (easiest first):
use NSObject's performSelectorOnMainThread:withObject:waitUntilDone: which is pretty self explanatory.
use performSelector:onThread:withObject:waitUntilDone:, which will let you go the other way
use an NSNotification (and NSDistributedNotificationCenter), though you can easily run into a race condition if you're not careful
Use NSPorts to send data back and forth
Check out the doc that Abizer mentioned for details on all of these.
performSelectorOnMainThread:withObject:waitUntilDone: is often the easiest way to update the UI with a background thread's progress. You could also create your own storage area that's safe to access between threads using NSLock or a similar mechanism, or even use distributed objects (which also works between processes or over a network).
Then there's NSOperationQueue and NSOperation which does help a lot to simplify multi-threaded programming, although a lot of programmers have been avoiding it since it can cause a crash in certain circumstances under Leopard.
Have a look at the Apple docs for this.
You may need to create an ADC member account, but this is free
Multi-threaded Cocoa Programs
I'm going back over some crufty code to tidy it up and I see I've been retaining NSTimers returned from scheduledTimerWithTimeInterval:target:selector:userInfo:repeats: and storing them in a field - then releasing and nulling the field when it fires. In some cases I use the timer to send an invalidate message to it later - but in many cases not.
In more recent code I usually just schedule the timer and forget about it. I understand that the constructor method is autoreleasing and the timer is retained by the run loop while it is active - so I don't see any issue with this.
So, just to round out my understanding - is there any other reason I should be holding on to my timers, or is what I am doing now the accepted idiom?
This is all in the context of iPhone code, but I don't believe this is iPhone specific.
I just let the run loop handle the retention, myself - it's the run loop that owns the timer and not me. If you see what I mean.
I'm answering my own question.
I was mostly asking the question because I'd been browsing through the class reference docs and this issue was not really made clear. I've since read the Timer Programming Topics: Using Timers article in the ADC and it covers it pretty well - especially the section on memory management at the end.
According to that what I am doing now (just scheduling, unless I need to be able to call invalidate, or isValid etc) is the right way.