Rowan Worth <row...@dug.com> writes:
> On 28 October 2016 at 02:53, Rolf Ade <r...@pointsman.de> wrote:
>
>> 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.
>>
>
> I'm not familiar with the TCL side of things, but in the C API "timeout"
> installs its own "busy" handler (which sleeps for a moment and then returns
> 0, or 1 if the timeout has been exceeded).
>
> There can only be one busy handler, so my guess is that the most recent
> call to "timeout" or "busy" will determine whether your busy handler or
> sqlite's timeout handler gets called.
It is in fact, as you suspected from knowing the C side.
This script illustrates this:
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} {
puts "busyhandler called"
}
sqlite3 two tmp.db
two busy busyhandler
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
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
