> Hell if I know why they use fcntl() for locks, and don't even give > you the option to block.
I think because they need to detect dead locks. BTW, I believe in case of dead lock even busy_handler will not be called, just SQLITE_BUSY is returned... > I think we are a long way from me screwing around with sqlite's > source. What I'm trying for is a solution with my own source code. Then neither flock() nor fcntl() will not help you. Your own code have control only over the busy handler which gains control only when database is locked. And it should understand somehow when other process not calling any busy handlers unlocks database... And I believe there's no solution here any better than simple sleep-and-retry. Pavel On Fri, Sep 18, 2009 at 1:47 PM, Angus March <an...@uducat.com> wrote: > Pavel Ivanov wrote: >>> The kernel grants them: http://www.manpagez.com/man/2/flock . Or I >>> might use fcntl(). >>> >> >> That's why I've asked what is different here from what SQLite already >> does because SQLite uses fcntl() on database file already. You can try >> > > Then it must use fcntl() with F_SETLK which doesn't block. If it > used F_SETLKW then it would block, and I guess I wouldn't be in this > mess. Hell if I know why they use fcntl() for locks, and don't even give > you the option to block. > >> to change it to flock() of course but be aware that SQLite needs more >> lock grades than flock() provides. >> > I think we are a long way from me screwing around with sqlite's > source. What I'm trying for is a solution with my own source code. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
