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

[Andrewlanoix aol com]

There is one thread per iochannel regardless of how many watches for that channel.

Here is what is going on:

1)  g_io_add_watch()is called with G_IO_IN.
2)  The select thread is started and combines all the existing watch conditions and select() returns on any one of those conditions. Since there is only one watch with G_IO_IN, the select thread goes to sleep until it can return with the G_IO_IN equivalent.
3)  g_io_add_watch()is called with G_IO_OUT. It is added to the list of things to watch for. However, the select thread has gone to sleep and will not wakeup until it gets one of the conditions it knew about before it went to sleep. This was G_IO_IN only, hence the problem.

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.

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>
> 
> _______________________________________________
> gnet-dev mailing list
> gnet-dev gnetlibrary org
> http://www.gnetlibrary.org/mailman/listinfo/gnet-dev
> 
> 
>