On Wed, 23 Apr 2025 10:51:53 +0200
Kristian Amlie <[email protected]> wrote:
>On 20.04.2025 17:53, ichthyo wrote:
>>
>> Hello Yoshimi-devs,
>>
>> generally speaking, Logging is a notorious and obnoxious topic.
>> While most developers want it "just to work", anyone who has been around
>> in this
>> business for long enough can share a lot of "war stories" related to
>> logging.
>>
>> That being said -- I'd like to bring up the question how relevant /
>> necessary /
>> heartfelt is the current state-of-affairs actually? Does anyone really care
>> that the logging works as it works now in Yoshimi?
>>
>> I'm asking because its one of the recurrent pain points whenever you're in
>> the unfortunate situation of doing any kind of maintenance work.
>>
>> Currently
>> - a significant fraction of all usages of these horrible synth-
>> pointers or
>> references passed around almost everywhere are just due to the
>> SynthEngine
>> being abused for logging -- a concern which really is not related to
>> generating sound -- it just seems convenient, because ....
>>
>> - we have separate loggers per Engine instance (theoretically the logging
>> settings could even be configured differently for each instance)
>>
>> - but this is only relevant if the user has configured the log messages
>> to go to the "console" widget in the GUI
>>
>> - in which case they will be dumped into a std::list, which is one of
>> the slowest containers, as each entry causes memory allocations and
>> pointer based data structures are bad for the cache performance
>>
>> - and last but not least, the way it is done is not threadsafe;
>> the main thread and the background thread and the GUI thread are
>> contending for the same container. If the GUI just happens to
>> remove the last log entries while e.g. the background thread
>> adds new ones, we'll get a memory corruption. Leading to those
>> kind of crashes that happen rarely, and are never reproducible.
>>
>>
>> A bit of wishful thinking:
>> If it turned out that we do not actually need all that sophistication...
>> Then there could be a single static logging function as entrance point,
>> which dumps all messages into a ringbuffer. And the GUI thread could
>> pull them out and write them either to STDERR or into a single widget
>> related to the "primary synth"
>>
>> What do we need logging for?
>> - see start-up messages to draw conclusion when the connection fail
>> - see error messages when loading corrupted data from XML
>> - see error messages when file system operations somehow fail
>> - maybe there are some special diagnostics sometimes relevant for devs
>> - the sound-testsuite also watches STDOUT to interact with Yoshimi
>> - and then the audio backends have the tendency to flood the log
>> with messages, which in some cases are also relevant for diagnostics
>>
>> Maybe we could reconsider and discuss that topic a bit more...
>
>All the suggestions here sound reasonable to me.
>
>Loggers are a pain point in almost every project, but a single static
>one tends to be the least painful in my experience. All other
>alternatives tend to have such a big impact on how code is tied
>together, either through function signatures or class members.
It hadn't even occurred to me that our logging code might not be thread-safe :(
The extensions I added were mostly about being able to direct the output in a
more granular manner and to different destinations. Several of us had a go at
getting FLTK to put new entries at the bottom, and scroll up as necessary.
This, of course, is not need when directed to the CLI.
--
Will J Godfrey {apparently now an 'elderly'}
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
_______________________________________________
Yoshimi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
