Maybe you are looking for semaphores. These can be tricky to use correctly in the case of cooperating processes, where you have to handle the case of the current owner of the semaphore terminating within the monitored section of code.
-----Ursprüngliche Nachricht----- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von test user Gesendet: Freitag, 16. August 2019 01:35 An: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Betreff: [EXTERNAL] Re: [sqlite] Getting a notification when a write lock is released. Thanks Simon, > You can use any other combination that suits you. Perhaps set a short > timeout, after which SQLite calls your busy handler, which can do > whatever it wants then return SQLITE_BUSY to your program. When the > short timeout gets exhausted, SQLite calls your own busy handler, and > /that's/ your notification. > > None of these would use the hint system or try to monitor files directly. > As you see, there's an existing way to monitor locks. You don't need > to abuse a different notification which isn't really suited to this purpose. The reason for the notification is to minimize time spent waiting. Lets say you can categorize the time spent waiting for a lock into these sets: - A. Time waiting whilst lock is locked. - B. Time waiting whilst lock is unlocked. With the current locking system, if you have many processes contending for write locks, time spent in set B will be > 0. With a notification when the lock is released, B can equal 0 for the duration of the system uptime. I understand the current lock system works well, and that this is a more complex system. Regarding your short timeout suggestion: Is polling the lock frequently in very short intervals resource intensive? Is SQLITE_ENABLE_SETLK_TIMEOUT the best way to try and implement this in my own library? On Thu, Aug 15, 2019 at 11:08 PM Simon Slavin <slav...@bigfraud.org> wrote: > On 15 Aug 2019, at 10:43pm, test user <example.com.use...@gmail.com> > wrote: > > > Currently the API lets you set a timeout. Does this just retry again > after a set amount of time? > > SQLite's built-in busy handler (which it uses unless you tell it to > use yours instead) repeatedly backs off and retries until the timeout > you set is complete. The amount of time it backs off for is decided > internally and you cannot depend on it being the same amount of time > every time. The entire time the busy handler takes should never much > exceed the amount of time you set as your timeout. > > > But I was thinking more along the lines of keeping BUSY and the > > current > locking system as is, but using the notification as a hint, that is > possibly unreliable. > > > > E.g. if BUSY (try again (after x seconds OR when hint arrives)) > > The assumption behind SQLite is that you will do one of three things. > The first of them is what most users do: > > 1) Set a long timeout, but not set your own busy handler. Then let > SQLite handle the wait-and-retry loop until it finally gives up and > returns SQLITE_BUSY. Then your program announces that the database is > inaccessible and quits (or gives up that function). > > 2) Set no timeout and no busy handler. Receive and handle SQLITE_BUSY > by doing whatever the program finds suitable. Perhaps implement your > own wait-and-retry loop, perhaps do something a lot more > sophisticated, appropriate to whatever the user expects. > > 3) Set no timeout and implement your own busy handler. > > You can use any other combination that suits you. Perhaps set a short > timeout, after which SQLite calls your busy handler, which can do > whatever it wants then return SQLITE_BUSY to your program. When the > short timeout gets exhausted, SQLite calls your own busy handler, and > /that's/ your notification. > > None of these would use the hint system or try to monitor files directly. > As you see, there's an existing way to monitor locks. You don't need > to abuse a different notification which isn't really suited to this purpose. > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___________________________________________ Gunter Hick | Software Engineer | Scientific Games International GmbH | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 1 80100 - 0 May be privileged. May be confidential. Please delete if not the addressee. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
