Re: [gnet-dev] GNet 2.0 Win32 plan and multi-watch issue



On Wed, 14 May 2003 Andrewlanoix aol com wrote:
> I will make a note of this problem in the Glib source code and I am
> going to move on to Gnet 2.0 since it avoids this problem. I think my
> time would be better spent getting a Gnet 2.0 version out for windows.
> (Server and Conn objects are also considered experimental in 1.1.x as
> well.)I will do a gnet 2.0 release that only supports IPv4 to start
> with to get it out more quickly.

I agree - if it's a problem in GLib 1.2, don't worry about it.

Check out the code in CVS.  I've made some changes to the Win32 code.

David



> If anyone has any pressing issues with gnet 1.1.x on win32 (other than
> above) that need to be fixed let me know.
>
> Andy
>
>
> In a message dated 5/14/2003 10:47:51 AM Eastern Standard Time, dhelder umich edu writes:
>
> >
> >
> > 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>




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]