If Parser::will_cursor_give_char is set to not error if a char matches
or the next line is empty, return Ok(bool). If this_if_nothing_ahead is
set to false, then return a NotEnough error if no more chars are
available.
The newly added test explains why
It is likely that we'll change the HashMap implementation in the future,
hence its best to hide away the HashMap to make sure we can easily
replace it.
The previous logic was heavily flawed; it only had to check if the path
was a dir and isn't the remote snapshot directory.
Similarly, the file name parsing should only kick in if the item is a
file
This commit adds changes so that the main process almost immediately
acquires a lock on the data file when runtime is dropped. This is just
an added precaution to try and ensure that no other process does
something silly with the data file.
The descriptor is cloned for this using `FileLock::try_clone`
8e46e62 added a block_on_process_exit function that kept on sending
`notify_one()`s in a loop until the services terminated. This was
pointless as the `Drop` impl would do it for us anyways.
(What was I thinking?)
So, in main(), we're spawning an async task that lets the DB run as long
as we don't pass a ctrl_c (or some bad panic occurs). Once the ctrl_c
is received, we start terminating all workers. `block_on` returns DB
which should be the only one holding an atomic reference to the shared
field. We assert this right after dropping `runtime`.
Finally, the ECONNRESET suppression match was fixed to remove an
unreachable branch by adding conditional compilation
This commit ensures that the workers exit before attempting a flush_db
operation. Only after block_on_process_exit finishes we return `db`.
Now we run a simple flush_db operation knowing that the lock has been
released.
To block on process termination, we introduce a new function
block_on_process_exit that does the same thing as CoreDB's Drop
implementation.
Windows is the most ingenious OS in the world where filenames can
conflict with shell commands. That's right, con is an I/O device on
Windows and cannot be used for a filename! This is why we were having
checkout errors on Windows!
Vive la POSIX!
We have introduced a trait `BufferedSocketStream` that is a 'dummy'
trait and is implemented for both `SslStream<TcpStream>` and
`TcpStream`. So, the generic `Connection` object accepts any type that
implements the `BufferedSocketStream` trait (and hence should also
implement `AsyncWrite`)
This commit does a LOT! It migrates the `queryengine::execute_simple`,
`CoreDB::execute_query` and the kvengine functions to use generic
connections.
The object dbnet::Con was removed because it isn't needed anymore.
The listeners were also upgraded to use the generic connection handler
The trait `Con` and `ConOps` were renamed to `ProtocolConnectionExt`
and `ProtocolConnection`.
This naming scheme clearly explains that the Ext version 'augments' the
non-Ext impl. This is the very case here: ProtocolConnection provides
the basic funtions needed for interfacing with net I/O while the Ext
trait enables high-level interaction with the protocol and ultimately
queries.
A generic `ConnectionHandler` object was added that will replace the
SSL and non-SSL handler objects, again reducing redundancy.
Dummy execute functions were added to CoreDB and queryengine.
Sayan Nandan