This guarantees that the caller of the start function will know whether
the worker is running by looking at its state.
This will prevent multiple successive stop calls to a worker which
happened when the monitors were altered via the REST API.
In tests, the log can now be setup as
int main()
{
mxb::Log log;
...
}
That will initialize the log so that it logs to a file called
<program-name>.log in the current directory and finalize it
when the program exits.
If any part of initalization fails, no resources are held.
At finalization, release all resources.
Also re-implement recent changes made to log_manager.cc that
did not automatically move over to log.cc.
Basically a copy of maxscale/debug.h, but with some name changes.
- ss_dassert -> mxb_assert
- ss_info_dassert -> mxb_assert_message
- ss_debug -> MXB_AT_DEBUG
Almost a verbatim copy of log_manager.[h|cc] with mxs changed
to mxb. The changes allow the MaxScale log manager to be moved
on top of this implementation.
The current implementation of mxs_log_message() is otherwise
generic, but for the fact that the session id is automatically
injected into the message.
With this change, a mxs_log_init2() is introduced that in addition
to the existing parameters takes a function using which the context
can be provided. The implementation of mxs_log_init() now simply
calls mxs_log_init2() giving a function that provides the MaxScale
context.
This is in preparation for moving maxscale/log_manager.h to
maxbase/log.h.
SLES 15 doesn't have any sort of init functions which is why the error is
converted to a status message. A dummy file that just prints an error is
placed into /etc/init.d/ to make it clear to the users that they should
use systemd to start MaxScale.
The function should not be an inline function with a static variable. This
appears to cause problems on at least Debian Wheezy and is likely to cause
odd behavior on other platforms.
Also renamed the file to <maxbase/string.h> to better mirror how the
<string.h> file behaves.
- The ones that were not used were removed.
- The ones that were used were moved close to the actual type.
In most cases some values were missing and if the definition is
close to the type there is a remote chance that they will stay
in sync. If detached, they surely will not.
