I certainly apologzize, to rise this a third time; I will stop to do it again.
Still, I think the documentation of the busy method of the Tcl interface to sqlite http://sqlite.org/tclsqlite.html#busy lacks the information, that the callback procedure will be called with one argument. Rolf Ade <r...@pointsman.de> writes: > I apologzize to rise this again, it may have fallen under the radar for > some reason. It is minor, too. > > The documentation of the busy method of the Tcl interface to sqlite > > http://sqlite.org/tclsqlite.html#busy > > doesn't tell, that the callback procedure is called with one arg, the > "number of times that the busy handler has been invoked previously for > the same locking event" (as the documentation sqlite3_busy_handler() at > https://www.sqlite.org/c3ref/busy_handler.html words it). > > The documentation also doesn't note, how the timeout and busy methods > interfere. > > The appended script illustrates the current implementation. > > rolf > > package require sqlite3 > > sqlite3 one tmp.db > one eval { > CREATE TABLE IF NOT EXISTS some(value text); > INSERT INTO some VALUES('foo'); > BEGIN IMMEDIATE TRANSACTION > } > > proc busyhandler {args} { > global counter > puts "args: '$args'" > incr counter > if {$counter > 3} { > return 1 > } > return 0 > } > > sqlite3 two tmp.db > two busy busyhandler > > catch {two eval { DELETE FROM some }} errMsg > puts $errMsg > two timeout 500 > catch {two eval { DELETE FROM some }} errMsg > puts $errMsg > two busy busyhandler > catch {two eval { DELETE FROM some }} errMsg > puts $errMsg > > > > Rolf Ade <r...@pointsman.de> writes: >> The documentation of the busy method at >> >> http://sqlite.org/tclsqlite.html#busy >> >> should be more specific, with regards of the arguments of the Tcl >> callback procedure. >> >> The documentation currently reads: >> >> The "busy" method, like "timeout", only comes into play when the >> database is locked. But the "busy" method gives the programmer much >> more control over what action to take. The "busy" method specifies a >> callback Tcl procedure that is invoked whenever SQLite tries to open >> a locked database. This callback can do whatever is desired. >> Presumably, the callback will do some other useful work for a short >> while (such as service GUI events) then return so that the lock can >> be tried again. The callback procedure should return "0" if it wants >> SQLite to try again to open the database and should return "1" if it >> wants SQLite to abandon the current operation. >> >> This doesn't specify, what arguments the Tcl callback procedure must >> expect. Turns out, that the proc is called with one argument (the number >> of how much the busy callback was already called for the current lock >> situation, it seems). That should be explictly written in the >> documentation, since it doesn't seem clearly obvious. >> >> What must be obvious is, that English is a foreign language to me. >> Therefor, I'm shy to propose a phrase. >> >> Another plea, since I'm already writing: It isn't immediate and without >> any doubt clear, how the "timeout" and the "busy" methods play together, >> if both are used. I suspect, the timeout, if given, determines, how long >> it lasts until the busy callback is called (and that for every round, if >> the busy callback returned "0") but if it is this way (or not) isn't >> said somewhere, if I see right. >> >> rolf >> >> _______________________________________________ >> 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 _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users