> On Feb 26, 2020, at 5:53 AM, Graham Holden <sql...@aldurslair.com> wrote:
>
> Wednesday, February 26, 2020, 11:15:14 AM, Richard Hipp <d...@sqlite.org>
> wrote:
>
>>> On 2/25/20, Peter Kolbus <peter.kol...@gmail.com> 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 dont 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()?
>
> I've not looked at the source, so I don't know whether what I think
> Peter is saying is correct or not, but what I THINK Peter is implying
> there's POSSIBLY some decision (based on HAVE_USLEEP) in the "core"
> SQLite code about what sort of timeout to ask for, before the request
> gets handed over to the VFS to implement.
Thanks Graham, this is exactly what I’m pointing out.
>
> Presumably, in the default VFS implementation(S) this also uses
> HAVE_USLEEP to decide whether sub-seconds times are possible or not.
The UNIX VFS implementation does test HAVE_USLEEP in unixSleep(). The Windows
VFS looks like it supports subsecond times as well but doesn’t use this flag.
>
> However, a custom VFS may have its own way of implementing sub-second
> delays (but does not implement usleep() itself)... it could therefore
> honour a request for sub-second delay if asked. However, to be asked,
> it has to "lie" about supporting usleep() and define HAVE_USLEEP.
>
> It may simply be a concern over semantics: i.e. whether HAVE_USLEEP
> means ("implements the function usleep()" vs. "can do short delays
> somehow") or it might be a deeper problem in that if you define
> HAVE_USLEEP (to allow a custom VFS to be asked to sleep for short
> amounts) it also causes other parts of the SQLite code to try and use
> usleep() when it isn't implemented).
My primary concern is indeed semantics, especially as not setting HAVE_USLEEP
with a custom VFS leads to worse performance when multiple threads are
contending for a lock. (I’m prepared to go through the exercise of defining
this for my company’s products, but wanted to raise the question first since
other SQLite users could well be missing out on performance).
Every other use of a HAVE_XXX define that I’ve ever seen, indicates a function
or header file is available. The second option Graham suggests (can do short
delays) doesn’t seem to be consistent with the Winflows VFS, as
sqliteDefaultBusyCallback() also tests SQLITE_OS_WIN.
The second concern is probably not a concern for SQLite if the project defines
SQLITE_OS_OTHER, but there could be problems for other software components that
take HAVE_USLEEP to mean that usleep() is available.
>
>
> Graham
>
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
