[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] glib changes checked in

From: josh
Subject: Re: [fluid-dev] glib changes checked in
Date: Fri, 01 May 2009 20:10:09 -0400
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

Quoting Pedro Lopez-Cabanillas <address@hidden>:

Builds now with msys/mingw32, with a little change to configure.ac (required
to link against winsock), but I've not tried yet with MSVC.

The executable doesn't work, though: it aborts abruptly after the greeting,
without clues.

Is it possible to debug or get some sort of backtrace?

Some notes on using glib:
Replace code which verifies function inputs with g_return_if_fail and
g_return_val_if_fail (i.e., programming errors)

We should probably avoid using glib memory allocation functions,
especially when allocating lots of memory, since they terminate the
application instead of returning NULL

Testing and feedback welcome!

What about fluid_hash.* and fluid_list.* ?

In regards to the statement about memory allocation terminating the application? I think internally a lot of glib uses g_malloc and friends, which will indeed terminate on an out of memory condition. I hadn't really thought of the full implications of this before, since it will have this effect on any application that FluidSynth is being used from.

On Linux, applications generally never will get a NULL from malloc(), but the Kernel may decide to kill the process if the system runs out of memory. I've always kind of programmed with the assumption that an out of memory condition is fatal and application termination is probably fine.

FluidSynth can use a lot of memory for sample data though, so it may often be the case that some user tries to load up a SoundFont that is much larger than what their system can handle. It would be bad if this then aborted whatever other program happened to be using FluidSynth as a shared library. We can use g_try_malloc(), which just acts like malloc(), for larger allocations. But that still doesn't stop a smaller one from taking down the program.

Does this seem bad enough to warrant not using glib, is the question..



reply via email to

[Prev in Thread] Current Thread [Next in Thread]