sqliteDefaultBusyCallback and HAVE_USLEEP

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

sqliteDefaultBusyCallback and HAVE_USLEEP

Peter Kolbus-2
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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqliteDefaultBusyCallback and HAVE_USLEEP

Richard Hipp-3
On 2/25/20, Peter Kolbus <[hidden email]> 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
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqliteDefaultBusyCallback and HAVE_USLEEP

Graham Holden
Wednesday, February 26, 2020, 11:15:14 AM, Richard Hipp <[hidden email]> wrote:

> On 2/25/20, Peter Kolbus <[hidden email]> 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()?

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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqliteDefaultBusyCallback and HAVE_USLEEP

Peter Kolbus-2


> On Feb 26, 2020, at 5:53 AM, Graham Holden <[hidden email]> wrote:
>
> Wednesday, February 26, 2020, 11:15:14 AM, Richard Hipp <[hidden email]> wrote:
>
>>> On 2/25/20, Peter Kolbus <[hidden email]> 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()?
>
> 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
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users