[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: 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

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

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.



reply via email to

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