Posix setup¶
Wiring the POSIX adapters. Posix covers what they fill and what they leave to you; the config fields are documented on the structs themselves.
What to link¶
POSIX is a stable system interface rather than a header-configured upstream, so
the adapters compile straight into libSolidSyslog.a. There is nothing extra to
link:
The message-queue buffer needs the POSIX message-queue functions, which sit in
librt on glibc before 2.34 and in libc from 2.34 onwards. Selecting this
platform puts rt on the library's public link interface, so a CMake consumer
inherits it and has nothing to add. If you consume libSolidSyslog.a directly -
a manifest build, or your own makefile - add -lrt yourself on the older glibc.
Wiring a sender¶
struct SolidSyslogResolver* resolver = SolidSyslogPosixResolver_Create();
struct SolidSyslogAddress* address = SolidSyslogPosixAddress_Create();
struct SolidSyslogStream* stream = SolidSyslogPosixTcpStream_Create(NULL);
static struct SolidSyslogStreamSenderConfig senderConfig;
senderConfig = (struct SolidSyslogStreamSenderConfig) {0};
senderConfig.Resolver = resolver;
senderConfig.Stream = stream;
senderConfig.Address = address;
senderConfig.Endpoint = MyEndpoint;
struct SolidSyslogSender* sender = SolidSyslogStreamSender_Create(&senderConfig);
For UDP, build a SolidSyslogPosixDatagram and a SolidSyslogUdpSender
instead; the resolver and address are the same. Passing NULL to the TCP
stream takes the default connect budget - supply a config to override it per
instance.
Tear down in reverse order, and destroy everything you created.
The callbacks¶
SolidSyslogConfig takes the clock, hostname and process id as callbacks
rather than components, and this platform supplies one of each ready to use:
SolidSyslogPosix_GetTimestamp, SolidSyslogPosix_GetHostname and
SolidSyslogPosix_GetProcessId. Use them directly, or wrap your own if the values
should come from somewhere other than the operating system.
Threading¶
If your application logs from one thread and drains from another, put a
circular buffer between them with SolidSyslogPosixMutex filling the mutex
role. Where Log and Service run on the same thread, inject
SolidSyslogNullMutex_Get() instead: a NULL mutex is refused as bad configuration and
Create returns the Null buffer.
The message-queue buffer needs SolidSyslogPosixMutex whenever Log and
Service run on different threads, not only when several threads log: the
kernel keeps the queue itself consistent, but the two threads share the buffer's
record of whether the queue has filled. Inject SolidSyslogNullMutex_Get() only
when one thread both logs and drains.
When it does not work¶
Install an error handler before you start; error severity says what each level is telling you.