Change Details

Currently, `kbx/backend-sqlite.c` uses three phase setup for `info_cb` with `dotlock_create`, `dotlock_set_info_cb` and `dotlock_finish_create` . This can be done with, say, `dotlock_create_with`, supplying the call back function. And, we can change the semantics of call back function to be responsible to all about emitting message. (Currently, it could only handle specific reason, `kbx/backend-sqlite.c` only handles `DOTLOCK_WAITING`)

Currently, `kbx/backend-sqlite.c` uses three phase setup for `info_cb` with `dotlock_create`, `dotlock_set_info_cb` and `dotlock_finish_create` . This can be done by a single step, say, with `dotlock_create_with`, supplying the call back function. And, we can change the semantics of call back function to be responsible to all about emitting message. (Current use case: `info_cb` could only handle a specific reason; `kbx/backend-sqlite.c` only handles `DOTLOCK_WAITING`, leaving other reasons to the dotlock implementation.)

Currently, `kbx/backend-sqlite.c` uses three phase setup for `info_cb` with `dotlock_create`, `dotlock_set_info_cb` and `dotlock_finish_create` . This can be done withby a single step, say, with `dotlock_create_with`, supplying the call back function. And, we can change the semantics of call back function to be responsible to all about emitting message. (Currently, use case: `info_cb` could only handle a specific reason; it could`kbx/backend-sqlite.c` only handle specific reason, `kbx/backend-sqlite.c` only handles `DOTLOCK_WAITING`s `DOTLOCK_WAITING`, leaving other reasons to the dotlock implementation.)