"Darryl Green" <darryl.green@unitab.com.au> wrote in message news:loom.20041030T055250-159@post.gmane.org...
Beman Dawes <bdawes <at> acm.org> writes:
But a dependency on any thread library is likely to throw cold water on my use. Here are the likely scenarios:
* Light-duty uses in light-duty non-multithreaded programs, where introducing a threading dependency seems far too heavy-weight for the apps.
There really isn't one in this case - see below.
* Heavy-duty industrial uses. I'm not adverse personally to a threading library dependency for these apps (which are sold as libraries); , but I'd have to get permission from managers who will be very concerned about use of a threading library clashing with customer's use of other threading libraries. Whether these concerns are valid or not is almost beside the point; it will be a hassle.
The library actually supports overriding the types used for logging including the threading primitives used, which (unless you use the ts_appender) is only a simple mutex and corresponding scoped lock class. So you should be able to keep those managers happy by using/wrapping other mutex/lock classes.
I don't recognize that, is it documented somewhere?
... it would be nice if there was a basic subset of features that could be used without threading concerns.
There is. Much of this can be addressed by better docs, but there is still some level of flux in how the internals (including the types exposed to allow alternative implementations to be assembled) fit together, so detailed docs on the architecture might take a while to arrive. In the meantime:
[snip]
3) Something quite radically different such as a log where the "stream" is something into which structured log information can be assembled, and the "string" carries that information to appenders that use that structured information (format it for textual output, write it to a database table...).
Is this actually possible? How? // Johan