Add a `pending_ops` field to `InnerLinuxIO` struct which is incremented
for each operation submitted to the ring and decremented when they are
taken off the completion queue. With this, we can exit from run_once if
there are no pending operations. Otherwise, in that case, it would hang
indefinitely due to call of `ring.submit_and_wait(1)`
Closes#349
Adds a struct WrappedIOUring which contains a IoUring and a pending_ops
field. Entry submission and popping from the queue is done through
functions operating on it, which also maintains pending_ops count
NOTE: This is a bit weird/hacky since in get_completion we create a
CompletionQueue and just call its next(). If it were a normal iterator
it would always return the same first item. However it is a queue posing
as an iterator which makes this work.
Add a `pending_ops` field to `InnerLinuxIO` struct which is incremented
for each operation submitted to the ring and decremented when they are
taken off the completion queue. With this, we can exit from run_once if
there are no pending operations. Otherwise, in that case, it would hang
indefinitely due to call of `ring.submit_and_wait(1)`
This is not related to any open issue (atleast from the ones I saw).
This is related to an issue I saw when running the simulator as it was
calling `io.run_once()` even before submitting any read/write job. This
would lead to it hanging since io_uring's submit_and_wait would keep
waiting for a completion event.
I've tried to improve the simulator's IO handling a bit:
We inject a fault before calling next_row() through which we'll get
pread faults. Also we call io's run_once on getting RowResult::IO. This
is run with a fault probability of 1%. This is less because a fault here
would result us in terminating the entire loop iterating on rows, and
also because realistically we'll expect less faults here.
PS: I think run_once() should not hang either when no operation is
pending in io_uring. Opened #349 for fixing that.
Closes#348
We inject fault before calling next_row() through which we'll get pread
faults. Also we call io's run_once on getting RowResult::IO. This is run
with a fault probability of 1%. This is less because a fault here would
result us in terminating the entire loop iterating on rows, and also
because realistically we'll expect less faults here
In the current implementation, there is an issue with the `min`/`max`
functions when the input contains both numbers and text. This merge
request fixes the problem.
I have also changed the `minmax` function by splitting it into two
separate functions to be able to add unit tests for both functions, just
like for the other functions
Closes#347
- Limbo command line shell supports e.g. `SELECT x'616263';`
- `EXPLAIN SELECT x'616263';` lists the opcode
Missing:
- Command line shell not entirely compatible with SQLite when blobs have
non-printable characters in the middle (e.g. `SELECT x'610062';`)
- Python bindings not supported (incoming soon)
Closes#343
- Limbo command line shell supports e.g. `SELECT x'616263';`
- `EXPLAIN SELECT x'616263';` lists the opcode
Missing:
- Command line shell not entirely compatible with SQLite when blobs have
non-printable characters in the middle (e.g. `SELECT x'610062';`)
- Python bindings not supported (incoming soon)
Bump operations per run but more importantly turn "ascending" option so
that we process pull requests with smaller IDs first that are more
likely to be stale.
Closes#337
Bump operations per run but more importantly turn "ascending" option so
that we process pull requests with smaller IDs first that are more
likely to be stale.
### sqlite
<img width="792" alt="image" src="https://github.com/user-
attachments/assets/1a9238db-d948-4583-a808-f9adfec7c534">
### limbo
<img width="809" alt="image" src="https://github.com/user-
attachments/assets/ea3e5f7e-bb3e-450d-be34-59ca00128beb">
### Changes
- Add support for `sqlite_version()` function
- Update function's explain message depending on the number of arguments
Closes#335
### Changes
- Remove clippy warning messages
- Add `#[allow(clippy...)]` in places where it might be better not to
fix
### TODO
recommended changes by `cargo fmt` on my local and github differs on
`sqlite3/src/lib.rs`. Should check for the reason
=> just upgrade the rust toolchain
Closes#329
Related to #144
- Separates `glob` and `like` regex caches, since the same pattern would
result in a different regex depending on which rules you apply
- Also fixes the value of `constant_mask` when translating LIKE
expressions now that non-constant pattern values are supported.
Note that LIKE and GLOB are almost entirely the same, the only
difference being the matching rules (so in our case, the regex
construction).
Closes#334
Per the sqlite docs, LIKE is case-insensitive.
> The LIKE operator does a pattern matching comparison. The operand to
the right of the LIKE operator contains the pattern and the left hand
operand contains the string to match against the pattern. A percent
symbol ("%") in the LIKE pattern matches any sequence of zero or more
characters in the string. An underscore ("_") in the LIKE pattern
matches any single character in the string. **Any other character
matches itself or its lower/upper case equivalent (i.e. case-insensitive
matching)**. Important Note: SQLite only understands upper/lower case
for ASCII characters by default. The LIKE operator is case sensitive by
default for unicode characters that are beyond the ASCII range. For
example, the expression 'a' LIKE 'A' is TRUE but 'æ' LIKE 'Æ' is FALSE.
The ICU extension to SQLite includes an enhanced version of the LIKE
operator that does case folding across all unicode characters.
Note that sqlite does not support case-insensitive comparisons of
unicode characters by default. This PR _does not_ match that behavior
currently. I can change things to not support unicode-case-
insensitivity, but as I understand it, doing so may require disable the
unicode-case feature on the regex crate, and potentially using a
`regex::bytes::Regex`, instead of a `regex::Regex`. (Basically, doing
some stuff that would not match anyone's initial assumptions about how
this would work).
Closes#333
