|
From: | josh |
Subject: | Re: [fluid-dev] glib changes checked in |
Date: | Sat, 02 May 2009 15:59:31 -0400 |
User-agent: | Internet Messaging Program (IMP) H3 (4.1.6) |
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 issueis 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
[Prev in Thread] | Current Thread | [Next in Thread] |