[asterisk-dev] sleeping in a module

[Thomas Andrews]

On Sat, Aug 12, 2006 at 10:31:31PM -0500, Tilghman Lesher wrote:

> > > ----- Thomas Andrews <tandrews at grok.co.za> wrote:
> > > > Do you really think so? I would have thought that the socket on
> > > > the odbc interface would block if there was a lock on the db,
> > > > so why can't I block too?
> > >
> > > I don't believe there is any concept of a database being 'locked'
> > > in the ODBC world normally, although certainly queries can take
> > > significant amounts of time to complete, so that's nearly the
> > > same thing.
> >
> > I'm completely ignorant when it comes to databases. I just assumed
> > that it must be possible for the underlying db (eg mysql) to have
> > some kind of record locking to avoid race conditions. But I agree
> > with you that delays amount to the same thing. If access is via a
> > TCP socket, then there definitely will be some kind of select/poll
> > between the db and odbc not so? If true, then it will definitely
> > re-schedule.
> 
> To my knowledge, only TDS-based databases (i.e. Sybase and MS SQL
> Server) have this limitation exposed to the user.  Other databases
> should correctly handle this for you, independent of user API calls.
> To combat the problem in TDS-based databases, res_odbc has been
> redesigned to handle multiple connections per connection class (i.e.
> connection pooling).  This is available in trunk and will be available
> in the upcoming 1.4 release.

I had a look at the changes you refer to, and I couldn't see any way of
adapting these ideas to the percieved problem that sqlite creates. The
return value of sqlite_step() can be one of the following:

    SQLITE_BUSY, SQLITE_ROW, SQLITE_DONE, SQLITE_ERROR, or SQLITE_MISUSE

>From the sqlite docs:

    "If the virtual machine is unable to open the database file because
    it is locked by another thread or process, sqlite_step will return
    SQLITE_BUSY. The calling function should do some other activity, or
    sleep, for a short amount of time to give the lock a chance to clear,
    then invoke sqlite_step again."

The way I see it, I have no option but to call sched_yield().