Hi there I've got a real pain in the proverbial problem with an app that runs multiple threading.timers as in:
'Instaniate the timer to refresh the memory cache of pi points (tags)
_tagRefreshTimer = New Threading.Timer(New Threading.TimerCallback(AddressOf TagRefresh), Nothing, Timeout.Infinite, Timeout.Infinite)
'Instaniate the timer to check for new files to process
_fileCheckTimer = New Threading.Timer(New Threading.TimerCallback(AddressOf FileCheck), Nothing, Timeout.Infinite, Timeout.Infinite)
'Instaniate the timer to check for dynamic setting changes
_settingsTimer = New Threading.Timer(New Threading.TimerCallback(AddressOf SettingsRefresh), Nothing, Timeout.Infinite, Timeout.Infinite)
Each of the timers can be configured to run at different intervals:
_tagRefreshTimer.Change(_tagRefreshInterval, _tagRefreshInterval)
_settingsTimer.Change(_settingsRefreshInterval, _settingsRefreshInterval)
_fileCheckTimer.Change(_fileCheckInterval, _fileCheckInterval)
I expected that these timers, since they are running in separate threads, would run happily in parallel with each other; however, this has not proven to be the case in practice. What happens is that two of the three will run together, but for some reason the third does not get an opportunity to fire. If I put a break point in the code, and wait for a few seconds, then continue, the third one sometimes does fire, however only at that point, thereafter it disappears into the background.
I'm wondering If I have some sort of race condition going on here, though I have to say as I mentioned at the start since threading.timers run in their own thread and in this context are not conditional on content from the main thread, I was simply not expecting this issue. Anyone have any idea what is going on here and how I might circumvent it?
Ok guys, I've traced the problem to my attempts to pause each of the three different timers using 'Timeout.Infinite' under certain conditions from within the competing callbacks. For example when the tag refresh was taking place I wanted to pause the file check process until the tag refresh had completed, and vice versa. It seems that even though each of the timers was switched back on once the task was completed, something was preventing the timers from acting as expected. Have cleaned up the code now and all timers are firing as expected and callbacks are completing as expected. App is now functioning as intended so consider this query answered. Thanks again for your input :-)
Kind Regards
Paul.
Related
Since a few days I try to figure out how to test my API with GHUnit. Now I came to the problem to test this:
The API gets some several inputs, the CUT does something and starts an NSTimer. After the timer fired, it sends out an NSNotification with some userInfo data. It is clear how to test the userInfo data, but what I want to test is, if the notification is sent only if some certain circumstances are true and if not, it shouldn't be send at all.
How I can test it, is quite clear after reading this: http://www.hpique.com/2013/12/nsnotificationcenter-part-3/
But now the logical problem streaks in: The asynchronous behaviour of the CUT with sending out the NSNotification after the NSTimer fired. When I wait now in every test for the timer to fire, then my tests will get really slow.
How can I test the behaviour without always waiting for the NSTimer to fire? Do you have any ideas?
I don't know a way to execute synchronous tests concurrently with XCTest from within Xcode. Of course you could define several test projects and run them concurrently from the console. But I guess, this is not what you are looking for.
An asynchronous test would require that the test method returns before the assertions have been tested, but will be tested eventually. A test runner would need to know about asynchronous tests in order to handle them correctly.
With XCTest, it's not possible to have an asynchronous test. There are hints in the source code documentation which makes me believe, that this is likely not possible at all:
In the description to waitForExpectationsWithTimeout it states:
"-waitForExpectationsWithTimeout:handler: creates a point of synchronization in the flow of a test. Only one -waitForExpectationsWithTimeout:handler: can be active at any given time, but multiple discrete sequences of { expectations -> wait } can be chained together."
"waitForExpectationsWithTimeoutruns the run loop while handling events until all expectations are fulfilled or the timeout is reached. Clients should not manipulate the run loop while using this API."
So, only one waitForExpectationsWithTimeout:handler: can be active and we must not modify the underlying run loop -- this quite clearly indicates that we cannot execute tests asynchronously.
Note: you can test asynchronous methods or functions within the test method. However, in XCTest the test method itself is always synchronous - since it waits for the result to become available.
I'm using GPUImageFilter in a chain, and most of the time it works OK. I've recently come across a few random crashes that match the symptoms in this github issue (albeit I'm using GPUImageFilter not live capture or video). I'm trying to find a suitable method that can ensure I've cleared the frame buffer and any other GPUImage-related activities in willResignActive.
Currently I have:
[[GPUImageContext sharedFramebufferCache] purgeAllUnassignedFramebuffers];
Is this sufficient? Should I use something else instead/in addition to?
As indicated there, seeing gpus_ReturnNotPermittedKillClient in a stack trace almost always is due to OpenGL ES operations being performed while your application is in the background or is just about to go to the background.
To deal with this, you need to guarantee that all GPUImage-related work is finished before your application heads to the background. You'll want to listen for delegate notifications that your application is heading to the background, and make sure all processing is complete before that delegate callback exits. The suggestion there by henryl is one way to ensure this. Add the following near the end of your delegate callback:
runSynchronouslyOnVideoProcessingQueue(^{
// Do some operation
});
What that will do is inject a synchronous block into the video processing pipeline (which runs on a background queue). Your delegate callback will block the main thread at that point until this block has a chance to execute, guaranteeing that all processing blocks before it have finished. That will make sure all pending operations are done (assuming you don't add new ones) before your application heads to the background.
There is a slight chance of this introducing a deadlock in your application, but I don't think any of my code in the processing pipeline calls back into the main queue. You might want to watch out for that, because if I do still have something in there that does that, this will lock your application. That internal code would need to be fixed if so.
I have a timer that talks to java objects through LS2J. It has only to call some getters of the java objects and to update the GUI with new values. This causes the GUI in iNotes Client to show the "Busy" cursor very shortly when the timer ticks. I is really annoying because it occurs even when another window is open and even in the designer.
I actually have to expect that the functionality in the timer event will get more complicated in the future, so I don't want to solve the problem by making my handler lighter.
Is there a way to tell iNotes client not to show this cursor or even an alternative way to make this regular check without timers?
The NotesTimer class in Notes client (not iNotes) does take over the foreground when it triggers, so there will be a bit of a delay if you do something that takes time to execute. It's possible to set up the Notes client to execute background scheduled agents in local database replicas, so that might be an option. You can to the heavy lifting in background and deposit the results somewhere -- say, in a profile document -- that can be accessed quickly by the UI code.
Alternately, you could try a XPages in the client application. I believe it can do partial refreshes while other stuff is going on.
For the record, I simplified the functionality of the Java call by preparing the data so that the timer only has to read the results. I also made the timer run every 3 seconds instead of 1.
Now I don't see any flicker!
I'm using Selenium WebDriver to get some content from a site that dynamically loads it using Ajax. I created a custom Wait class to check for a condition on the page to make sure that the page has loaded before continuing. I used FluentWait to set the polling interval to 2 and timeout to 10. However, I noticed that it checks for the first time at time increment 0, then waits 2 seconds if the condition was false, then checks again, etc.
Since the page takes some time to load, it always is false at the first check, but usually is true at the second. Is there any way to make Wait wait the 2 seconds before checking for the first time? I.e. check at times 2,4,and 6, if necessary, rather than at 0,2,4,and 6?
Thanks,
bsg
EDIT
I've been asked to mention why I want this behavior - after all, I'm using the Wait the way it's meant to be used. The benefit I get from it returning true the first time is the following: WebDriver apparently opens a new socket every time it issues a command to the browser. For whatever reason, these sockets don't always get closed after the call executes. When executing a large number of calls in a short time (for instance, when repeatedly checking for a condition, which is what Wait does), it is possible to run out of virtual sockets, and the driver crashes. (The lack of enough virtual sockets seems to be a known issue on Windows 7, but I can't modify my system.)
The fewer calls to the driver I issue in a short period of time, the less likely it is to overrun the number of available sockets. I have observed that the first check never returns true, and therefore it's just opening a socket for no reason, making the program more likely to crash. That's why I want to wait. I hope this explanation is helpful for someone searching for information as to why they keep getting SocketExceptions in WebDriver.
The obvious answer would be to just insert a time.sleep(2) (or similar method) before your first check. Would that work for what you're trying to do?
In an iOS app, I'm writing a class that will be messaged, go do a background request (via performSelectorInBackground:withObject:), and then return the result through a delegate method (that will then be displayed on a map). Everything seems to work right when one request is happening at a time, but I'm trying to figure out how to handle multiple overlapping requests. For example, if a user enters something in a search box that starts a background thread, and then enters something else before the initial background thread completes, how should this be handled?
There are a few options (don't let the second request start while the first is in progress, stop the first as soon as the second is requested, let both run simultaneously and return independent results, etc.), but is there a common/recommended way to deal with this?
I don't think there's universal answer to this. My suggestion is to separate tasks (in form of NSOperations and/or blocks) by their function and relationships between them.
Example: you don't want add image resizing operation to the same queue with fetching some unrelated feed from web, especially if no relationship between them exists. Or maybe you do because both require great amount of memory and because of that can't run in parallel.
But you'd probably want to add web image search operations to same queue while canceling operations of the same type added to this queue before. Each of those image search operations might init image resize operation and place it into some other queue. Now you have an relationship and have to cancel resizing in addition to image search operation. What if image search operation takes longer than associated resize operation? How do you keep a reference to it or know when it's done?
Yeah, it gets complicated easily and sorry if I didn't give you any concrete answers because of uniqueness of each situation but making it run like a Swiss clock in the end is very satisfying :)