Re: [gnet] Use of conn and experimental IO functions

[David Helder <dhelder umich edu>]

On Tue, 14 Jan 2003, Tim Muller wrote:
> On Tuesday 14 January 2003 21:25, David Helder wrote:
>
> > I'm considering moving the experimental IO functions in GNet
> > (gnet_io_channel_read_async, gnet_io_channel_write_async) to the GConn and
> > simplifying them.  They are difficult to use and bug prone (due to the
> > Linux/GLib poll problem).
> >
> > Is anyone using them?  Is there any objection?
>
> Hmm, I am using gnet_conn_readany() and gnet_conn_write(), so I assume that
> these will be affected by your changes, right?

Ok, great.  The prototypes would change, but they'll still be there.

I'm especially interested if anyone is using the 9 arg read() function.
Anyone using it could use the new READADBLE/WRITEABLE events if they need
finer control of reading and writing.

The new functions are tricky for me to do because the callback may destroy
the conn and the callback may call gnet_conn_read() again (in the new
API).  Handling this has been a headache in the past.  Though I have a
better idea of how to do it now.

> What is going to happen to the timeouts? Are they just not going to be
> implemented, or is the value set with gnet_conn_timeout() being used?

Use gnet_conn_timeout().  I felt setting a timeout on the read/write was
redundant.


> btw, what's the Linux/glib poll problem? (I am asking because I have some code
> with an io_channel and a pipe, and that code works perfectly fine on linux,
> but not at all on FreeBSD, and I just can't make it work on FreeBSD).

Each iochannel corresponds with a socket descriptor.  Internally, GLib
calls poll using these file descriptors.  Each watch corresponds to a
pollfd in the array passed to poll().  In Linux, if there are more entries
in this array than open file descriptors, the kernel returns an error.
This is POSIX compliant, but unnecessary and anoying.

So, if you have a watch on read and a watch on write on each of your
IOChannels and you have more than 3 or so IOChannels, this call will fail.
GLib will continue calling poll and failing.  You'll never get a watch
called and CPU will go to nearly 100%.

I filed a bug against GLib a long time ago, but they haven't fixed it yet.
I'm not surprised - it's a pretty obscure bug.  The best thing for GNet to
do is work around it (and I should really submit a patch to them).

BTW, fixing GConn in the last major item on my TODO.  I will probably make
a 1.3 developer release after this.

David


-- 
      __          _    __ David Helder - dhelder umich edu
  ___/ /__ __  __(_)__/ / <http://www.eecs.umich.edu/~dhelder>
 / _  / _ `/ |/ / / _  /  DiaWebLog: <http://www.diaweblog.org>
 |_,_/|_,_/|___/_/|_,_/   Paper CD Case: <http://www.papercdcase.com>