So we have an app were the user needs to login. During the login data were downloaded from the internet and created into the Realm database.
If the app were closed and reopened we want the app to retain the user that has been logged-in so they don't need to relogin again. Everything is fine and ok during the first user login. When the app were closed and reopen the Realm database throws an error "Accessed from incorrect thread"...
I can't provide much of the code as I don't know where the issue is. I would like to know if rerunning the app again is it on different thread than before? and if it's then the how data created from previous thread can be accessed in the new thread without encountering the said error?
Any help will be appreciated... Thanks in advance
As you have encountered, you can't access a realm from a different thread than the thread it was opened. It is possible however to open multiple instances of the same realm on different threads (or the same thread if that's needed). Opening a realm is not an expensive operation, so there's not a performance issue in opening realms.
I'm guessing in your case that you're downloading the data on a background thread. I'm also guessing the realm is first opened in the callback to that network request. That means the realm is opened on the thread that callback is on. If you try to access that realm on the main thread when reopening the app (or any other thread that's not the same thread as before) you'll get an error.
Best practice is to open a new realm every time you know your doing work on a different thread. As I mentioned, this is not an expensive operation and should be used liberally.
If you have some sort of RealmService or RealmManager as a singleton, I'd recommend against it. If the realm is initialised on the main thread, you won't be able to add records to it from a background thread.
In short: whenever you are doing operations on a realm in a callback, unless you are 100% certain you are going to be on the same thread as you opened a realm on, create a new realm instance and use that to do your operatations.
Related
I'm working on a embedded solution where two apps are working: one is the user interface and the other runs in the background providing data for the UI.
Recently I came across with a memory leak or similar error that is making Linux kill the secondary process, leaving the UI in a stopped situation without telling anything for the user about what is going on. I reached the problem by reading Linux's message log file and the software's print on terminal "Kill -myapp".
My question is: how could I notice such an event (and other similar) coming from the secondary software so I could properly report it to the user and log it? I mean, it's easy to have a look time to time in the process 'tree' to see if the secondary app is running and, if it's not, report a "some event happened" in the UI and it's also plausible to have a error-handler system inside the secondary app that makes it write in a log file what just happened and make the UI read that file for new entries from time to time, but how could the UI app knows with better details what is going on in such more abrupt events? (in this case, "Linux killed process", but it could be a "segmentation pipe" or any other) (and if there is another, better solution that this "constant read a log file produced by the secondary app", I'ld also like to know)
Notes: the UI is written in C++/Qt and the secondary app is in C. Although a solution using the Qt library would be welcomed, I think it would be better for the entire programming community if a more generalized solution was given.
You can create a signal handler for POSIX signals such as SIGKILL in the backend process and notify the ui using for example another signal with sigqueue. Any IPC mechanism should work, as long as it's async safe. Read more about signals: tutorial and manual
It may still be a good idea to check from the ui side periodically because the handler might not succeed.
As for a better way to check if process is alive compared to reading the log file:
Check if process exists given its pid
I'm opening the sqlite database file with sqlite3_open and inserting data with a sqlite3_exec.
The file is a global log file and many users are writting to it.
Now I wonder, what happens if two different users with two different program instances try to insert data at the same time... Is the opening failing for the second user? Or the inserting?
What will happen in this case?
Is there a way to handle the problem, if this scenario is not working? Without a server side database?
In most cases yes. It uses file locking, but it is broken on some systems, see http://www.sqlite.org/faq.html#q5
In short, the lock is created when you start a transaction, and released immediately after. While locked, other instances can neither read nor write to the db (in "big" db, they can still read). However, you can connect sqlite in exclusive mode.
When you want to write to db, which is locked by another process, the execution halts for a specified timeout, by default 5 seconds. If lock is released, it proceeds with writing, if not it raises error.
I am using SQL Server Compact Edition 3.5 on a mobile device. Synchronisation using the sync framework works fine in the context of the user doing it via a button press and waiting for it to complete. There are no issues there.
I have recently attempted to do this in a background thread which runs every 'n' minutes or so. This also works fine, provided I am not using the database at the time. If I am using the database, the whole app locks up and I haven't yet found the specific exception that must be happening. I will continue to do that, but that is not part of my question.
My question is does the SqlCeClientSyncProvider somehow throw an exclusive lock or otherwise physically lock the .SDF file during synchronisation? If so, are there any options to override this behaviour?
No, it doesn't lock the .SDF file, after testing I see that at most it creates a transaction with a read committed isolation level. The issue I was having was a deadlocking issue in my own threading code -- which I was able to resolve after some careful refactoring. I was raising an event 'SyncBegun' before the sync happened and raising a subsequent event 'SyncEnded' afterwards. These were using separate locks which were stepping on each other's toes.
I made a MFC application which probably has two threads, one for receiving data from a socket using UDP protocol and one is the main thread of MFC app. While any data is received some objects, created in the main thread by new operator, would be notified to fetch the data through apply the observer design pattern. The problem is that sometimes after I clicked the close system button, the GUI of the app disappeared, but its process can still be found in the Task Manager. If I stop the data source (UDP client) this problem would never happen. Other important and maybe helpful information is listed below:
The Observer design pattern was implemented with STL container list. I have used the critical section protection in the Attach, Detach and Notify functions.
I deleted the observer objects before closing the UDP socket.
The data transfer rate may be a little faster than process data, because after closing the data source the data process is still working.
I can't figure out what lead my app can not exit completely. Please give me some clues.
This is usually caused by a thread you created and not exit it programmatically when you exit the appliation. There must be a while clause in your thread. The way to find where it is still running is:
use debug mode to start you application and click the exit button the top right corner to exit it.
Check from task manager and see if it is still running
if it is, excute Debug->Break All,
Open threads windows, double click each thread, you will find where your code is still looping.
Typically a process won't terminate because there's still a foreground thread running somewhere. You must ensure that your socket library isn't running any thread when you want to close your application.
First thing, with MFC, please use the notification based methods to get notifications on message arrivals, connections etc. So you can get rid of threads if you have.
It's quite easy to attache to a debugger and Break see which threads are existing and waiting for what.
Alternatively you can use ProcessExplorer with proper symbol configuration to see the call stacks of the threads available for the particular process.
The application can two kind of issues to exit, one could be infinite loop and other might be waiting/deadlock (e.g. socket read command is a blocking call). You can easily deduce the problem by attaching to debugger.
Otherwise please provide further information about the threads, code snippet possible.
I have an NSDocument-based Cocoa app and I have a couple of secondary threads that I need to terminate gracefully (wait for them to run through the current loop) when the users closes the document window or when the application quits. I'm using canCloseDocumentWithDelegate to send a flag to the threads when the document is closing and then when they're done, one of them calls [NSDocument close]. This seems to work peachy keen when the user closes the document window, but when you quit the app, it goes all kinds of wrong (crashes before it calls anything). What is the correct procedure for something like this?
The best possible way is for the threads to own the objects necessary for the thread to finish doing whatever it is doing to the point of being able to abort processing and terminate as quickly as possible.
Under non-GC, this means a -retain that the thread -releases when done. For GC, it is just a hard reference to the object(s) desired.
If there is some kind of lengthy processing that must go on and must complete before the document is closed, then drop a sheet with a progress bar and leave the document modal until done (both Aperture and iPhoto do exactly this).