On Tue, 3 Feb 2009 21:45:14 +0000 Robert Pearce <[email protected]> wrote: > On Tue, 3 Feb 2009, Chris Vine <[email protected]> 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 _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
