Johan Hedberg wrote:
> On Tue, Sep 18, 2007, Fabien Chevalier wrote:
>> As for the POLLOUT thing, i must say i'm confused..., and don't really 
>> see the link with the patch :-(
>> I guess it works already as the GIOChannels heavily rely on it.
> 
> GLib maps POLLOUT to G_IO_OUT, POLLHUP to G_IO_HUP, etc. I was saying
> that to conform to how other socket types behave[1] the callback should
> *not* be getting a HUP or ERR in this case but a OUT instead. As for
> applying the patch, I'm fine with it even though it in essence is a
> work-around for a kernel side problem. However, it's Marcel's call in
> the end.
> 
> [1] I have yet to verify this but that's what the connect(2) manpage
> implies (in the section about EINPROGRESS)

Ok, thanks, this time i understood. :-)
I wrote a test program that does an asynchronous connect using the IP 
stack. (I attached the file, you can dry run yourself if you're curious 
;-) ). On error we receive a revent with POLLERR value, and no POLLOUT.
Conclusion is:
   * POLLOUT is to be sent only when the channel is ready to send more data.
   * POLLERR is the right thing to send when we cannot establish the 
connection due to whatever error ==> The man page is a bit ambiguous 
about it.
   * which means the bt kernel part is fine and does not need fixing
   * which means my patch is not a workaround but a clean fix to this 
bogus error returning code :-)

Marcel, Johan, if you don't have any other remarks, you would mind 
applying the patch ?

Cheers,

Fabien