Re: Using Glib::IOChannel for socket connections

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 3 Feb 2009 21:45:14 +0000
Robert Pearce <rob bdt-home demon co uk> wrote:
> On Tue, 3 Feb 2009, Chris Vine <chris cvine freeserve co uk> wrote :
> >You can set the file descriptor returned by
> >socket() non-blocking and poll it in the same way as you can poll the
> >one returned by accept() (certainly you can do that with select() so
> >I imagine you can do it with Glib::SignalIO which uses poll() under
> >the hood). The callback will execute when there is a new connection
> >pending and you can call accept() on the file descriptor and
> >establish the client connection. This is the way you do it in
> >single-threaded programs.
> 
> I've done that in the past, and it does work. ISTR there was some
> oddity but it was small and easily solved. Might depend whether you
> need to be able to accept multiple connections. Possibly something to
> do with making a new IOChannel for the accept()'d connection.

Possibly making the socket file descriptor non-blocking makes the file
descriptor returned by accept() non-blocking for reading as well, which
may not be what the user wants, but if so a call to fcntl() on the new
descriptor will sort it out.

Technically I am not sure it is even necessary to make the socket
descriptor non-blocking but I would be nervous about calling accept()
on it, in the expectation that it will always return, on the basis
that it could never block on a successful poll(). I would bet there is
some corner case somewhere where that is not guaranteed.

I remember using this kind of technique some time ago also in a
single-threaded program that I wrote.

Chris