[asterisk-dev] sleeping in a module

[Thomas Andrews]

On Sat, Aug 12, 2006 at 11:25:24AM -0500, Kevin P. Fleming 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.
 
> > The thing is, if the db is locked, you have no choice but to sleep
> > or give up. I'd have thought that giving up would be worse. Calling
> > sched_yield() as I am should allow other threads to run enough to
> > unlock the db..
> 
> Right. I guess my point is that the Realtime API (and the users of
> Realtime) don't expect or make any provisions for Realtime calls to
> take extended periods of time, and depending on what the API call is
> being made for it could cause channel signaling to break and other
> unexpected behavior.

Yes. I'm working on the assumption that because sqlite is running on the
local machine, then it is only other threads that are competing for the
database. It should therefore be seldom that any delays are caused
because sqlite allows more than one thread to read the db simultaneously.
Only when one thread is writing will other tasks wait.

I really wish I understood asterisk architecture better :(

Anyway res_sqlite and res_config_sqlite are now complete and being
tested. All looks good so far.

Regards,
Thomas