After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 643074 - Incorrect documentation for g_socket_receive() and g_socket_receive_message()
Incorrect documentation for g_socket_receive() and g_socket_receive_message()
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: network
2.28.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-02-23 15:06 UTC by Chris Vine
Modified: 2011-04-09 16:55 UTC
See Also:
GNOME target: ---
GNOME version: 2.31/2.32


Attachments
Documentation patch (1.55 KB, text/plain)
2011-02-23 15:07 UTC, Chris Vine
Details

Description Chris Vine 2011-02-23 15:06:01 UTC
The documentation for g_socket_receive() and g_socket_receive_message() state that "If the socket is in blocking mode the call will block until there is some data to receive or there is an error".

This implies that a remote peer performing an orderly shutdown (which must cause the calls to unblock()) will be treated as an error by gio, but that is not the case.  The implementation of g_socket_receive_with_blocking() and g_socket_receive_message() only treat an error as arising if recv() and (for the posix implementation) recvmsg() respectively return a value < 0.  (Possibly the windows implementation of g_socket_receive_message() behaves differently, but I doubt it.)

I have tested that, on standard linux distributions, on remote orderly shutdown of the peer these gio functions unblock returning 0 rather than an error.

A documentation patch dealing with this will be attached.
Comment 1 Chris Vine 2011-02-23 15:07:47 UTC
Created attachment 181702 [details]
Documentation patch
Comment 2 Dan Winship 2011-04-09 16:55:12 UTC
committed a slight variant of this. thanks