News for hackers. Stuff that matters.
Re:Pack: A New Container Format for Compressed Files by cogman10 on Friday March 22, 2024 @04:54PM (#39794762)
> No parallel reads from multiple threads

Sqlite supports parallel reads from multiple threads.

It even supports parallel reads and writes from multiple threads.

What it doesn't really support is parallel reads and writes from multiple processes.

Re:Pack: A New Container Format for Compressed Files by raggi on Friday March 22, 2024 @05:13PM (#39794926)
Not when threading is disabled, as it is in this project.
Re:Pack: A New Container Format for Compressed Files by cogman10 on Friday March 22, 2024 @05:15PM (#39794944)
Sure, but single threading isn't an inherent part of sqlite as OP implies.

> SQlite3 automatically means:

...

> - No parallel reads from multiple threads

Re:Pack: A New Container Format for Compressed Files by OttoCoddo on Saturday March 23, 2024 @07:38PM (#39803830)
It is not disabled, as you think. It is secured by the internal code in Pack. Almost all parts of Pack are multithreaded.
Re:Pack: A New Container Format for Compressed Files by raggi on Sunday March 24, 2024 @10:54AM (#39807604)
it’s not safe to disable SQLite’s thread safety as you do here: https://github.com/PackOrganization/Pack/blob/main/Libraries... and then do your own locking. You attempt to pass the flag at open time to enable serialized mode, however quoting the SQLite docs for the build flag you set:

  Note that when SQLite is compiled with SQLITE_THREADSAFE=0, the code to make SQLite threadsafe is omitted from the build. When this occurs, it is impossible to change the threading mode at start-time or run-time.

SQLite’s APIs are often hazardous in these ways, it really should be erroring rather than silently ignoring the fullmutex flag, but alas.