Re: [gnet-dev] Re: Glib win32 iochannels update

[David Helder <dhelder umich edu>]

Yes, in 1.1.  In 2.0, only one watch is used.

Yes, if you select on all conditions, it will frequently return with
writable.  But that's ok if G_IO_IN is set.  Can you look at all watches,
merge the conditions together, select on that, and then figure out which
watches should be called?  Is there a thread per iochannel or a thread per
watch?

David



On Wed, 14 May 2003 Andrewlanoix aol com wrote:

> David,
>
> In ob_server_func(), gnet_conn_readline() calls
> gnet_io_channel_readline_async() which creates the first watch on the
> socket with G_IO_IN.
>
> The second watch is created by send_to() with gnet_conn_write() which
> calls gnet_io_channel_write_async() which does the G_IO_OUT watch.
> send_to() is called by the first callback.
>
> I don't know what goes on in *nix but the windows problem is isolated
> to giowin32.c. socket iochannels on win32 are implemented as one win32
> specific thread per socket inochannel.
>
> If I do a select on all conditions, won't it almost always return with
> saying it can write to the socket?
>
> Where do we go from here?
>
> Andy
>
>
> In a message dated 5/13/2003 10:50:15 PM Eastern Standard Time, dhelder umich edu writes:
>
> >
> >
> > On Tue, 13 May 2003 Andrewlanoix aol com wrote:
> > > I have discovered what the problem is, or at least the first problem.
> > > There is an issue with the way the socket threads in glib on win32 are
> > > synchronized when you add a second watch to the iochannel.
> > >
> > > Basically the code checks to see what conditions to look for, G_IO_IN
> > > etc across all watches and then does a select() call which goes to
> > > sleep on those conditions. It does not wake up until one of those
> > > conditions is met. This means that if you do a G_IO_IN, followed by a
> > > G_IO_OUT g_io_add_watch() call, the second will not happen until the
> > > first call happens on that socket.
> >
> > Ugh.  Multiple watches on a single IOChannel causes problems in Linux too.
> > Is this problem with the core GLib code or just with the Win32 specific
> > code?
> >
> > > The simple fix to this problem is to have a timeout on the select()
> > > call. When the timeout occurs do a continue; to restart the loop to
> > > reload the conditions to select() on. However, I do not know what a
> > > reasonable timeout should be. I am going to talk to David and
> > > investigate other options.
> >
> > Will that work?  The best solution would be to select on all the
> > conditions in first place.


-- 
David Helder - dhelder umich edu - <http://www.eecs.umich.edu/~dhelder>