Re: [fluid-dev] glib changes checked in

[josh]

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!
> >      Josh
>
> 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..


> Regards,
> Pedro

Regards,
Josh