Re: [sqlite] sqliteDefaultBusyCallback and HAVE_USLEEP
> On Feb 26, 2020, at 5:53 AM, Graham Holden wrote:
>
> Wednesday, February 26, 2020, 11:15:14 AM, Richard Hipp
> wrote:
>
>>> On 2/25/20, Peter Kolbus 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
Re: [sqlite] sqliteDefaultBusyCallback and HAVE_USLEEP
Wednesday, February 26, 2020, 11:15:14 AM, Richard Hipp wrote:
> On 2/25/20, Peter Kolbus 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.
Presumably, in the default VFS implementation(S) this also uses
HAVE_USLEEP to decide whether sub-seconds times are possible or not.
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).
Graham
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqliteDefaultBusyCallback and HAVE_USLEEP
On 2/25/20, Peter Kolbus 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 d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqliteDefaultBusyCallback and HAVE_USLEEP
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? Thanks, Peter ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
