GNOME Bugzilla – Bug 741707
Gsocket blocks trying to send data
Last modified: 2015-01-17 14:12:59 UTC
I am attaching on the next message a couple of programs (client, server) showing the problem.
Created attachment 292973 [details] client The client program
Created attachment 292974 [details] server The server program
Basically the problem is that if you get the fd from a socket that already sent and received some data. Then you create a gsocket out of it and you try to send something then the socket send blocks forever. If you try to do the same without sending or writing anything before you create the new gsocket out of the fd, then it works. This test seems to work fine on linux but as pointed out it fails on windows. I've been checking the code of gsocket and couldn't see anything specific. The problem seems to be a blocking issue on the line: https://git.gnome.org/browse/glib/tree/gio/gsocket.c#n2781
Created attachment 292975 [details] client A bit smaller test
Created attachment 292976 [details] server A bit smaller test
Created attachment 293188 [details] [review] gsocket: block when errno says it will block On windows it may happen we recreate a gsocket out of a fd from another gsocket that already got the FD_WRITE event. If this happens in order to get another FD_WRITE we need to have tried an operation that might need such event. What we do here is to first try to do the operation and then if errno specifies that we might block then wait for that event to occur.
Created attachment 293189 [details] [review] gsocket: block when errno says it will block On windows it may happen we recreate a gsocket out of a fd from another gsocket that already got the FD_WRITE event. If this happens in order to get another FD_WRITE we need to have tried an operation that might need such event. What we do here is to first try to do the operation and then if errno specifies that we might block then wait for that event to occur.
Created attachment 293190 [details] [review] gsocket: block when errno says it will block On windows it may happen we recreate a gsocket out of a fd from another gsocket that already got the FD_WRITE event. If this happens in order to get another FD_WRITE we need to have tried an operation that might need such event. What we do here is to first try to do the operation and then if errno specifies that we might block then wait for that event to occur.
Comment on attachment 293190 [details] [review] gsocket: block when errno says it will block >Subject: [PATCH] gsocket: block when errno says it will block I don't think that describes what the patch is doing very well... Also, maybe the commit body could be updated to mention that this is an optimization on unix too, as per bug 732439. I'm assuming that you've verified that "make check" still passes on linux with this patch, and that running the tests by hand on windows, you get no new failures. You should add a test case to gio/tests/socket.c that fails without this patch and succeeds with it. (It's OK if the test is Windows-specific if that's the easiest way to reproduce the bug.)
Created attachment 294225 [details] [review] testcase for the bug This testcase hangs on win32 without the patch and passes after the patch. It also passes on linux (with and without the patch) Incidentally maybe it would not be bad to have a portable g_dup (for now I included a static version in the testcase)
Created attachment 294226 [details] [review] patch Nacho's patch with the reworded commit message since nacho is currently on vacation
Comment on attachment 294225 [details] [review] testcase for the bug good, except: >+ client = g_socket_new (G_SOCKET_FAMILY_IPV4, >+ G_SOCKET_TYPE_STREAM, >+ G_SOCKET_PROTOCOL_DEFAULT, >+ &error); change those tabs to spaces please
Comment on attachment 294225 [details] [review] testcase for the bug amended as suggested and pushed
I'd like to cherry-pick these on stable, unless you think they are too risky.
*** Bug 732439 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > I'd like to cherry-pick these on stable, unless you think they are too risky. sure (though maybe wait until it's gotten a bit of testing on master)