This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [TEST] sqlite3-3.7.17-1 (Cygwin 1.7.19 locking feature)

On 6/4/2013 03:37, Corinna Vinschen wrote:

It would be nice to have a simple testcase (plain C, only Cygwin
POSIX calls, self-contained, yada yada) to see what sqlite expects in
POSIX lock mode.

SQLite locking is a hairball. It is spread over a range of about 2.5 kLOC within the 140 kLOC sqlite3.c file, and those routines are behind about three layers of indirection from the mainline SQLite code.

Mind, I'm not talking about the *callers* of this code here, just the locking routines themselves. Add in all the callers and *their* expectations and...well...<shudder>

I think we have to define the problem as "SQLite locking requires what SQLite requires today."

Luckily, while creating the -2 packages, I stumbled across a STC in SQL that replicates the reported problem:

$ ./sqlite3 foo.db 'create table fred(id integer, barney text)'
$ CYGWIN_SQLITE_LOCKING=posixmand ./sqlite3 foo.db \
  'insert into fred(barney) values("wilma")'

If you change the locking mode to either "bsd" or "posix", it doesn't fail. This gives hope that your new flock() implementation may work for us.

Here's hoping you can get the info you want from running the second command under strace.

I can tell you that it doesn't fail if you don't do a DB write. For example, this succeeds regardless of locking strategy:

$ ./sqlite3 foo.db .q

You can see it open the DB file and turn on mandatory locking, but since it doesn't write to the DB file, it doesn't actually call flock(). The same goes for the other two locking strategies.

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]