Re: sqliteDefaultBusyCallback and HAVE_USLEEP

On 2/25/20, Peter Kolbus <[email protected]> wrote:
> I noticed that sqliteDefaultBusyCallback() seems to depend directly on the
> OS (behave differently based on SQLITE_OS_WIN||HAVE_USLEEP).  Since the
> underlying primitive, sqlite3OsSleep(), actually uses the VFS to sleep, and
> unixSleep() also has a roundup to whole seconds when HAVE_USLEEP is not
> defined, any time resolution limitations are already handled there. And when
> a custom VFS is configured, that VFS may well be able to sleep in milli or
> microseconds using an RTOS-specific function that is not usleep() — for
> example FreeRTOS has osDelay().
>
> Is there a reason sqliteDefaultBusyCallback() has this dual implementation,
> and defining HAVE_USLEEP is correct to get better performance on platforms
> that don’t have usleep()? Or could it be simplified?
>

I don't think I understand the question.  It sounds like you are
asking why SQLite does not try to sleep for sub-second intervals on
systems that do not support usleep()?
-- 
D. Richard Hipp
[email protected]
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users