Re: [fluid-dev] glib changes checked in

[josh]

Quoting Pedro Lopez-Cabanillas <address@hidden>:

> On Saturday, May 2, 2009, address@hidden wrote:
> > 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.
>
> I've tried now, without success. It doesn't compile under msvc 2008 express.
> Lots of compiler errors regarding sockets in fluid_sys.c


Ok.  I probably didn't include some header file that is needed.  If  
you could send the compiler error output to me, that would help a lot.


> > >
> > > 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?
>
> It is not a crash, so there is no backtrace. I've attached the debugger
> output.


Ahh, I see what the problem is.  I had modified fluid_istream_gets()  
in fluid_sys.c to use recv() instead of read() in the case of WIN32,  
to handle TCP/IP sockets.  I hadn't considered the fact that this is  
used for stdin as well.  I guess this means that TCP/IP sockets and  
stdin cannot be treated the same, like in Unix.  I changed it back to  
read() for now, but that probably wont work in the TCP server case.   
Some other solution needs to be found.


> > > What about fluid_hash.* and fluid_list.* ?
> >
> > In regards to the statement about memory allocation terminating the
> > application?
>
> I was asking about your plans, if you are going or not to replace these
> sources by the original types from glib.

Yes, I think I will gradually replace some of the other data types.   
It should be transparent as far as the rest of the FluidSynth code is  
concerned.  I'd like to get over this first initial stage of getting  
it to build correctly on Windows.

> > 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.
> [...]
> > Does this seem bad enough to warrant not using glib, is the question..
>
> I'm not familiar enough with glib. The only problem that I see with   
> this issue
> is if the user won't be notified about the memory problem. This doesn't look
> like a very good quality indicator.

Glib likely logs this condition via its own logging mechanism.  If  
glib log messages were routed through the FluidSynth logging system  
(or visa versa), then this log message could be caught.  I kind of  
feel its not such a huge issue.

> Regards,
> Pedro

Josh