> when it moves on to build gobject, it hangs up while running
> glib-genmarshal. If I look at the task manager, ntvdm.exe is using
> a lot of CPU - why would glib-genmarshal be using the 16-bit VM?
Heh, no reason. One thing to look out for is that the
glib-genmarshal.exe you built needs to ru
On 11/16/05, Tor Lillqvist <[EMAIL PROTECTED]> wrote:
> See the patch below that clears up some of the issues: 1) After
> getting FD_CLOSE, make the knowledge of that "stick" and always set
> G_IO_HUP. 2) Plug a handle leak, WSACloseEvent the socket's event when
> the channel is closed.
>
> If you
Tor Lillqvist writes:
> See the patch below that clears up some of the issues:
Forgot to mention, 3) Calls WSAEnumNetworkEvents() only if the event
for the socket has fired. This means the spurious
WSAEnumNetworkEvents() calls you noticed being logged when just moving
the mouse don't happen any
> I fixed that (and what do you know... it works!). Thanks for noticing.
Good to hear!
> Should I make an attempt at the changes to giowin32.c, or is that
> something you've already got sorted out?
See the patch below that clears up some of the issues: 1) After
getting FD_CLOSE, make the knowled
On 11/15/05, Tor Lillqvist <[EMAIL PROTECTED]> wrote:
> There are some problems both in your code, and in giowin32.c.
>
> For efficiency, your code should not read just one byte at a time in
> the callback. It should read in bigger chunks, and as much as possible
> in a loop, until it gets a WSAEWO
There are some problems both in your code, and in giowin32.c.
For efficiency, your code should not read just one byte at a time in
the callback. It should read in bigger chunks, and as much as possible
in a loop, until it gets a WSAEWOULDBLOCK or an EOF. If it did this,
it would probably also work
On 11/14/05, Tor Lillqvist <[EMAIL PROTECTED]> wrote:
> > g_io_win32_check: WSAEnumNetworkEvents (1576, 0x618) revents={}
> > condition={IN|ERR|HUP} events={}
>
> > What seems to happen is that after watching a socket io channel once,
> > I'll continue to see these messages until I restart the prog
> g_io_win32_check: WSAEnumNetworkEvents (1576, 0x618) revents={}
> condition={IN|ERR|HUP} events={}
> What seems to happen is that after watching a socket io channel once,
> I'll continue to see these messages until I restart the program - even
> if the io channel should have been cleaned up by g
Greetings,
I'm having a strange problem in trying to get a program (gaim) working
with Glib 2.8.x (2.8.3) under win32.
I'm watching for IO on a socket using g_io_channel_unix_new(fd), and
then watching for the result using g_io_add_watch_full() (basically
using functionality modeled after gdk_inp
