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 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
