< ^ txt
Sun 17 Feb 2019 09:37:41 AM EST
Slept from twelve to eight without waking.
High of twenty-five today, with up to an inch of snow.
Goals:
- Lunch with Ed?
Done.
Found while trying to determine concurrency safety of SQLite in Go:
https://github.com/bvinc/go-sqlite-lite
As I understand it now:
- SQLite itself can be safe for concurrent writes, as long as each concurrent thing makes a new `fopen()` call.
- SQLite keeps this safe by managing its own write locks and mutexes.
- However, the Go `database/sql` expects to use connection pooling — keeping a group of open database connection to share between goroutines in order to minimize the overhead of opening new connections. Connection pooling is pointless (and potentially dangerous) for embedded databases like SQLite, where initiating new connections is a simple `fopen()`.
- One of the first and most popular Go packages for SQLite, `github.com/mattn/go-sqlite3`, is _not_ safe for concurrent writes _because_ it follows the the `database/sql` connection-pooling model. A package like `github.com/bvinc/go-sqlite-lite` that eschews the `database/sql` model and just lightly wraps the SQLite C calls can promise concurrency safety as long as we open a new database connection for each goroutine.
- For performance reasons, SQLite may be a poor choice for an application with heavy concurrent writes. But to quote the SQLite FAQ: "experience suggests that most applications need much less concurrency than their designers imagine".
- https://www.sqlite.org/lockingv3.html https://www.sqlite.org/wal.html
Ate lunch with Ed at The Corner Grill.
Not bad — pleasant atmosphere and reasonably tasty food.
(We forgot Bangkok Cafe closes on Sundays.)
Checked out Gate Keeper Games in Berkley.
Read some Iliad.
Watched anime.
Servings: grains 4/6, fruit 2/4, vegetables 3/4, dairy 1/2, meat 0/3, nuts 0/0.5
Breakfast: banana, carrots, cucumber, pear, chips and cheese, coffee
Lunch: cauliflower wrap
Afternoon snack:
Dinner: nachos
128/79
< ^ txt