History save thread

[takluyver]

OK, I think this is tidy enough to bring forward now.

@fperez requested that history be saved in a separate thread, so the UI was more responsive. Despite some initial reservations, that's what I implemented. When I test, I can actually see a difference on my computer (without the aggressive HDD spin down Fernando experiences). So I'm on board with the value of this now.

That said, this is still introducing an extra thread, so please go over it with a fine toothcomb looking for possible multithreading issues. So far, I've dealt with:

• SQLite connections can't be shared across threads, so we need a separate connection for the main thread and the save thread. This also means we can't use in-memory databases for the tests, because you can't have more than one connection to them. I've set a large cache size for the tests, so the performance hit is negligible.
• The input and output caches have locks surrounding their access (so if you execute a cell while it's writing out the cache, you'll still see a small hang while it finishes. There are ways round this, but it shouldn't be a common problem).
• We have to be sure to stop the thread safely when we close, or a mysterious thread traceback appears.

[fperez]

There's threading code in there, but honestly it doesn't bother me at all. As we discussed on IRC, this is precisely the kind of scenario where threads make sense (hiding latencies introduced by i/o from the user experience), and that every modern program with a non-trivial UI must use.

Your implementation looks great, it's very clean, and thanks to Python now offering locks as context managers, it's actually very readable and easy to inspect. Part of the nastiness of lock handling was even seeing that you were doing the right thing in the code, and context managers really help a lot with that.

I ran all tests and inspected the code, it looks very good to me. Some more discussion on irc...

[takluyver]

I've fixed up the things we discussed on IRC. We're going to leave this for a day or two in case anyone else wants to comment, then merge it if there are no objections.

[ellisonbg]

I am not thrilled about threads running in the background of the core. With the GIL, and all of the issues related to thread safety, it just doesn't make sense. I don't see the background discussion that prompted this effort. Was the issue related to the latency of sqlite io? (that is what it sounds like).

[ellisonbg]

Fernando, Min and I chatted on IRC and I think this approach does make sense. I looked through the code and the way the locks are handled look nice (with is great). This looks pretty good.

[fperez]

Thanks a lot for this, Thomas, I just pushed it since I had it open for testing while reviewing it once more with Brian.

Now that we've all had a chance to convince ourselves this is the right approach, we can close it.

Funny how I ended up being the one defending threads this time ;)