http://bugs.winehq.org/show_bug.cgi?id=9425
Summary: Select behavior different on Wine Product: Wine Version: 0.9 Platform: Other URL: http://www.winehq.org/pipermail/wine-devel/2006- February/044588.html OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-misc AssignedTo: wine-bugs@winehq.org ReportedBy: phil.lodwick@efi.com
#include "stdafx.h" #include <winsock2.h>
int _tmain(int argc, _TCHAR* argv[]) { SOCKET fd; WORD wVersionRequested; WSADATA wsaData;
wVersionRequested = MAKEWORD( 2, 2 ); WSAStartup(wVersionRequested, &wsaData); fd = socket(AF_INET, SOCK_STREAM, 0); if (fd != INVALID_SOCKET) { fd_set readfds; struct timeval select_timeout ;
FD_ZERO(&readfds); FD_SET(fd, &readfds) ; select_timeout.tv_sec=2 ; select_timeout.tv_usec=0 ;
if (select((int) fd+1, &readfds, NULL, NULL, &select_timeout) != SOCKET_ERROR) { if(FD_ISSET(fd, &readfds)) printf("THIS IS WINE\n"); else printf("THIS IS WINDOWS\n"); } else printf("got a socket error\n");
closesocket(fd); } return 0; }
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #1 from Vitaliy Margolen vitaliy@kievinfo.com 2007-08-23 07:51:11 --- It's helpful to know what this program should do on windows and Wine and how results are different.
Also please update Wine version, OS and hardware (in this bug).
http://bugs.winehq.org/show_bug.cgi?id=9425
Phil Lodwick phil.lodwick@efi.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|other |Windows XP Platform|Other |PC
--- Comment #2 from Phil Lodwick phil.lodwick@efi.com 2007-08-23 07:56:49 --- I found this bug in Feb-06. When I talked with Alexandre about it he was aware of the problem. However, Aug-07 Dan Kegel asked me to file a bug report.
I am not sure if there are any programs out there that rely on this behavior. The bug was much easier to work around than try to fix since Wine just implements Windows sockets with Linux sockets and there are differences.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #3 from Dan Kegel dank@kegel.com 2007-08-23 08:14:38 --- Created an attachment (id=7755) --> (http://bugs.winehq.org/attachment.cgi?id=7755) Same testcase, ported to Unix
Here's the testcase ported to Unix. When run on Linux, it behaves the same as the original testcase on Wine, as expected (since Wine just uses unix sockets).
I asked Phil to file this bug in response to his posts in which he described the gyrations he had to go through to work around it; see http://winehq.org/pipermail/wine-devel/2007-August/058819.html
If we run into another app that is annoyed by this issue, we might want to look again at whether wine can paper this difference over.
http://bugs.winehq.org/show_bug.cgi?id=9425
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov@gmail.com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #4 from Damjan Jovanovic damjan.jov@gmail.com 2007-08-24 02:36:18 --- This difference in select behaviour, along with several others, are already documented in dlls/ws2_32/tests/sock.c function test_select() in a todo_wine {} block.
It's relatively hard to implement in wine because we'd have to keep track for each socket what state it is in and modify several functions to use/modify that state correctly. I'm not sure any real world apps depend on it, after all you should only select on a socket when it can receive a change in I/O state.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #5 from Phil Lodwick phil.lodwick@efi.com 2007-08-24 04:18:11 --- Yes, I believe I added those tests:
2006-02-14 Phil Lodwick Phil.Lodwick@EFI.COM
* dlls/winsock/tests/sock.c: winsock/tests: select wakeup on closesocket. - Change select timeout from 2 seconds to 500 microseconds. - Add test to make sure select wakes up after a closesocket. - Add test to make sure listen fails without bind.
http://www.winehq.org/pipermail/wine-cvs/2006-February/020685.html
http://bugs.winehq.org/show_bug.cgi?id=9425
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Windows XP |Linux
http://bugs.winehq.org/show_bug.cgi?id=9425
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #6 from Austin English austinenglish@gmail.com 2008-10-22 14:24:07 --- Is this still an issue in current (1.1.6 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #7 from Austin English austinenglish@gmail.com 2009-04-26 20:37:55 --- Still an issue in 1.1.20.
Anyone object to closing this bug? We've got a testcase in for it, no need for a bug report as well...
http://bugs.winehq.org/show_bug.cgi?id=9425
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #8 from Dan Kegel dank@kegel.com 2009-09-15 12:15:13 --- It's ok to have both a testcase and a bug.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #9 from Austin English austinenglish@gmail.com 2010-04-29 18:07:29 --- Still a todo: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/ws2_32/tests/sock.c;h=8...
http://bugs.winehq.org/show_bug.cgi?id=9425
Ruediger Meier sweet_f_a@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sweet_f_a@gmx.de
--- Comment #10 from Ruediger Meier sweet_f_a@gmx.de 2012-02-05 07:00:23 CST --- There is another related case which is IMO very important.
1. Call connect() on a non blocking socket to a destination IP:port which will reject you. 2. Call select() with non zero writefds only.
Wine's select will return immediately with 0 which should only be returned after really timeouting!
Window's would return 0 after the specified timeout.
(I know that in real life I should wait on exceptfds too in the example above. Fortunately this works a expected.)
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #11 from Ruediger Meier sweet_f_a@gmx.de 2012-02-05 07:38:48 CST --- (In reply to comment #10)
(I know that in real life I should wait on exceptfds too in the example above. Fortunately this works a expected.)
My last statement here was not true.
It's a race condition. Sometimes exceptfds is set, sometimes not. Even worse I can't never get the right error 10061 ("connection refused") via getsockopt() even in case exceptfds was set.
This makes this bug IMO a major bug. I wonder if any application which deals with non blocking sockets is working as expected under wine.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #12 from Ruediger Meier sweet_f_a@gmx.de 2012-02-05 09:37:21 CST --- (In reply to comment #4)
[...] I'm not sure any real world apps depend on it, after all you should only select on a socket when it can receive a change in I/O state.
This is the case with non blocking sockets after calling connect, see
for Linux you need to select the writefds: 1. man 2 connect -> EINPROGRESS
but on Windows writefds and exceptfds: 2. http://msdn.microsoft.com/en-us/library/windows/desktop/ms737625%28v=vs.85%2... -> "Use the select function" 3. http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141%28v=vs.85%2... -> "Return value" and -> "In summary" -> "exceptfds"
which fails on wine.
http://bugs.winehq.org/show_bug.cgi?id=9425
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #13 from Bruno Jesus 00cpxxx@gmail.com 2012-02-05 09:40:00 CST --- Can you post a test to prove that like in comment 0? It would help a lot.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #14 from Ruediger Meier sweet_f_a@gmx.de 2012-02-05 11:26:46 CST --- (In reply to comment #13)
Can you post a test to prove that like in comment 0? It would help a lot.
It's not as deterministic as the case above but I try.
Here a test which should describe what is expected with non blocking sockets and refusing tcp connection in real life:
https://gist.github.com/1746651
You may attach that test here if useful and necassary.
cu, Rudi
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #15 from Bruno Jesus 00cpxxx@gmail.com 2012-02-05 12:00:01 CST --- (In reply to comment #10)
Wine's select will return immediately with 0 which should only be returned after really timeouting!
Window's would return 0 after the specified timeout.
Are you sure about this? If you try to connect to a closed port (in a host without firewall) the socket will receive the RST flag and windows will return as immediately as other systems. And if you try to connect to a non-existent host (or the port is closed and the host has a firewall) the connection attempt will return after the configured timeout value.
Thanks for the testing code, I'll try it as soon as I have time.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #16 from Ruediger Meier sweet_f_a@gmx.de 2012-02-05 12:36:28 CST --- (In reply to comment #15)
(In reply to comment #10)
Wine's select will return immediately with 0 which should only be returned after really timeouting!
Window's would return 0 after the specified timeout.
Are you sure about this? If you try to connect to a closed port (in a host without firewall) the socket will receive the RST flag and windows will return as immediately as other systems.
No, in opposite to other systems windows would only return immediately if I also select the "exceptfds" (which I'm doing in my test code but not in comment #10). But even these other systems would not return value 0 (=timeout) but 1 because they set writefds even if connection is broken.
And if you try to connect to a non-existent host (or the port is closed and the host has a firewall) the connection attempt will return after the configured timeout value.
Yes, this works as expected on wine.
Here a bit pseudo code how it should work comparing Linux and windows
on Linux: connect() // non blocking ret = selcet( ..., writefds, ... ) if (ret < 0) -> strange error if (ret == 0) -> timeout if (ret > 0) -> writefds is set, connection process finished, now we need to ask getsockopt if it was successful or not
on Windows: connect() // non blocking ret = selcet( ..., writefds, exceptfds, ... ) if (ret < 0) -> strange error if (ret == 0) -> timeout if (ret > 0) -> if writefds is set -> connection succesful if exceptfds is set (*) -> connect failed (we may ask getsockopt why)
So case (*) (the one that differs between win32 and linux) is the one that is broken in wine. Sometimes select returns 0 instead of >0 and setting exceptfds. And getsockopt seems to never tell us about any errors.
Thanks for the testing code, I'll try it as soon as I have time.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #17 from Bruno Jesus 00cpxxx@gmail.com 2012-02-05 13:14:39 CST --- In your test code there are 2 wrong behaviors, wine shows both of them while windows shows only the correct behavior?
Wine used to set the write FD wrongly if connection was refused but this was fixed.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #18 from Ruediger Meier sweet_f_a@gmx.de 2012-02-05 14:00:35 CST --- (In reply to comment #17)
In your test code there are 2 wrong behaviors,
Actually the 2 wrong messages are the same case. You may change line 54 from "} {" into "} else {" (like it would be in real world). I'd removed that else to see if there are cases where return value is wrong but sets are correct nevertheless. In real world we wouldn't check that because usually we trust select :)
wine shows both of them while windows shows only the correct behavior?
Yes windows is always correct according to the documentation. Sometimes wine is also correct. Chances are better if you use a remote IP instead of localhost. Try 149.20.4.69 (kernel.org) - they are rejecting instead dropping.
Wine used to set the write FD wrongly if connection was refused but this was fixed.
What version got this fixed? Maybe the fix simply does not manage to set exceptfds instead of writefds sometimes.
cu, Rudi
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #19 from Bruno Jesus 00cpxxx@gmail.com 2012-02-05 14:33:04 CST --- This is the fix that was commited to avoid false-positive write FDs: http://source.winehq.org/git/wine.git/commitdiff/bebc425bb52fde72611a767c732...
The base for that change was this comment: http://bugs.winehq.org/show_bug.cgi?id=21387#c10
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #20 from Ruediger Meier sweet_f_a@gmx.de 2012-02-05 16:56:11 CST --- Created attachment 38717 --> http://bugs.winehq.org/attachment.cgi?id=38717 ws2_32: Fix bug 9425, missing except fds on select()
(In reply to comment #19)
This is the fix that was commited to avoid false-positive write FDs: http://source.winehq.org/git/wine.git/commitdiff/bebc425bb52fde72611a767c732...
Thank's for pointing me to this!
Putting one and one together got me an easy patch to fix my issue (comment 11-18). Please review. See my commit message, allthough it sounds a bit unsure IMO it's more safe to apply that patch than leaving it.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #21 from Bruno Jesus 00cpxxx@gmail.com 2012-02-05 17:32:41 CST --- Does it remove any of the TODOs from the socket test file? If not you have to add a new test there and prove it fixes this problem (it's usually the only way to get a code change in).
You seen to be using k_w2e without initialization if no write FDs are set.
Maybe there will be an overflow of the exceptfds array because of doubled fds, isn't it?
General wine coding rules: Stick to the coding near the changes (see how { is used in the next line instead of in the end of the line) Don't add {} if there is only one line in the if/else.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #22 from Ruediger Meier sweet_f_a@gmx.de 2012-02-05 18:12:04 CST --- (In reply to comment #21)
Does it remove any of the TODOs from the socket test file? If not you have to add a new test there and prove it fixes this problem (it's usually the only way to get a code change in).
Just did it quick and dirty but I'll watch it over again this week. Also I think get_poll_results() becomes quiet unreadable now so probably it should be split into a 2 patches (refactoring and fix).
You seen to be using k_w2e without initialization if no write FDs are set. Maybe there will be an overflow of the exceptfds array because of doubled fds, isn't it?
Thx, your point highlights my original comment 10. We must not even return from WS_select() in case the user doesn't wait on exceptfds. But looking at WS_select() there is now way to prevent this with fixing get_poll_results() alone. BTW would we even enter get_poll_results() if user only selects exceptfds? Looks like we have to know about this move in WS_select() already.
General wine coding rules: Stick to the coding near the changes (see how { is used in the next line instead of in the end of the line)
Sry, I was happy to see you are not using GNU style but missed that it's not 100% kernel style;)
Don't add {} if there is only one line in the if/else.
Hehe, I don't like this rule because if you would always add {} from the beginning then any future additions will make the diff smaller (also it's easier to add temporary debug lines) - accepeted anyway.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #23 from Bruno Jesus 00cpxxx@gmail.com 2012-02-05 18:34:24 CST --- (In reply to comment #22)
Thx, your point highlights my original comment 10. We must not even return from WS_select() in case the user doesn't wait on exceptfds. But looking at WS_select() there is now way to prevent this with fixing get_poll_results() alone. BTW would we even enter get_poll_results() if user only selects exceptfds? Looks like we have to know about this move in WS_select() already.
As far as I remember get_poll_results is always called if poll returns != -1. The timeout is respected only if poll returns error as seen in: http://source.winehq.org/source/dlls/ws2_32/socket.c#L3752
About the conding style I was just following common rules I see often in other users reviewing =)
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #24 from Bruno Jesus 00cpxxx@gmail.com 2012-02-05 20:11:44 CST --- Your patch must also take care that a socket in the writefds may not be in the exceptfds. So it may not as simple as joining the two fors.
http://bugs.winehq.org/show_bug.cgi?id=9425
Ruediger Meier sweet_f_a@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org
--- Comment #25 from Ruediger Meier sweet_f_a@gmx.de 2012-02-07 17:44:52 CST --- Does anybody still remember why exactly we've applied 0082973d "Convert WS_select to use poll() instead of select()".
I mean the whole patch is difficult to read and POSIX select behaves very similar to Windows. The writefds -> exceptfds move would be much easier to do.
Replacing select by poll without _any_ behavior change is even a challenge without emulating another system.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #26 from Juan Lang juan.lang@gmail.com 2012-02-07 17:51:48 CST --- (In reply to comment #25)
Does anybody still remember why exactly we've applied 0082973d "Convert WS_select to use poll() instead of select()".
For one thing, select is limited in the number of files it can select on, to FD_SETSIZE.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #27 from Dan Kegel dank@kegel.com 2012-02-07 18:20:15 CST --- select() is utterly broken if the program uses more than 1024 file descriptors of any kind. (It's still safe to use if you pass it no file descriptors, which people do sometimes for a portable sleep() with finer resolution.)
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #28 from Ruediger Meier sweet_f_a@gmx.de 2012-02-08 14:15:35 CST --- (In reply to comment #26)
(In reply to comment #25)
Does anybody still remember why exactly we've applied 0082973d "Convert WS_select to use poll() instead of select()".
For one thing, select is limited in the number of files it can select on, to FD_SETSIZE.
Don't we have that on Windows even limited to 64 per default? Or is this a problem in wine because fds are all living together in wineserver?
However I see the current select emulation broken in several ways:
1. POLLHUP can happen always without subscribing it. Since a file descriptor can (and usually will) be listed twice in our pollfd array it's undefined which particular pollfd struct will receive a POLLHUP. I saw any thinkable cases happen. It's only luck if a POLLHUP will finally make it into exceptfds.
2. IMO it's questionable whether we should always put POLLHUP into exceptfds at all.
3. Since we ignore some events (so possibly all events) we must poll again to really timeout instead of returning 0 without timeouting.
4. POLLPRI (OOB data) is completely ignored currently.
5. What about POLLERR and POLLNVAL? Can't they happen because of our checks before calling poll?
To fix 1. we need would need a real mapping fd -> "select fds" rather than just mapping array positions. If we had this then we also could more cleanly sort the events into the right "select fds" when we think about 2-5.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #29 from Damjan Jovanovic damjan.jov@gmail.com 2012-02-08 22:37:05 CST --- (In reply to comment #28)
(In reply to comment #26)
(In reply to comment #25)
Does anybody still remember why exactly we've applied 0082973d "Convert WS_select to use poll() instead of select()".
For one thing, select is limited in the number of files it can select on, to FD_SETSIZE.
Don't we have that on Windows even limited to 64 per default? Or is this a problem in wine because fds are all living together in wineserver?
On Windows, select() takes an array of 64 file descriptors, which can have any values. On Linux, select() takes a bitset of 1024 bits. Even if you want to select() on just one file descriptor with value 2000, you can pass it to Windows as an array element, but on Linux, you can't even set that bit.
It was in bug 3063 that select() was rewritten on top of poll(), fixing a file descriptor leak in eMule.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #30 from Bruno Jesus 00cpxxx@gmail.com 2012-02-09 10:04:15 CST --- (In reply to comment #28)
- POLLHUP can happen always without subscribing it.
Since a file descriptor can (and usually will) be listed twice in our pollfd array it's undefined which particular pollfd struct will receive a POLLHUP. I saw any thinkable cases happen. It's only luck if a POLLHUP will finally make it into exceptfds.
Yes, it can happen and it's quite natural sometimes. For example a broken connection is detected when select() sets the READFD and when you try to recv() on that fd you will receive 0 meaning the connection was half-closed, wine's current implementation lets that happen. poll() should behave the same in all systems (posix compliance) but it's well know it does not =)
- IMO it's questionable whether we should always put POLLHUP into exceptfds at
all.
I've been thinking about this but only tests can prove this and it will probably vary in the different windows versions.
- Since we ignore some events (so possibly all events) we must poll again to
really timeout instead of returning 0 without timeouting.
Usually wine coding strategy is to implement things required for real life applications to run. There are plenty network applications running really well in wine currently, I think the best example is uTorrent because it uses hundreds of sockets sending/receiving data and it works fine. If you find a real application that depends on this I think the best thing to do is open a new bug report for it, this bug is just to generic =)
- POLLPRI (OOB data) is completely ignored currently.
POLLPRI is not needed there currently, usually the strategy is to use the OOBINLINE check and then recv() with MSG_OOB. The wine server already takes care of some POLLPRI stuff as seen in http://source.winehq.org/source/server/sock.c#L324 select() does not return weather there is or not priority data. A real life app example is putty which works in wine currently using the telnet protocol. Maybe you say we should test (POLLIN | POLLPRI) in poll to return the readfds? I don't have objections if that's the case.
- What about POLLERR and POLLNVAL? Can't they happen because of our checks
before calling poll?
Yeah, I think POLLNVAL will never happen. And POLLERR is also not required because the current conditions for read/except will allow setting the fd in this case.
To fix 1. we need would need a real mapping fd -> "select fds" rather than just mapping array positions. If we had this then we also could more cleanly sort the events into the right "select fds" when we think about 2-5.
I don't understand what's wrong with the current implementation =)
To convert the write fd errors in exceptions you could use a fd_set to insert the writefd errors and then in the exceptfs For you could check this fd_set together with the curren check.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #31 from Ruediger Meier sweet_f_a@gmx.de 2012-02-09 16:41:02 CST --- (In reply to comment #30)
(In reply to comment #28)
- POLLHUP can happen always without subscribing it.
Since a file descriptor can (and usually will) be listed twice in our pollfd array it's undefined which particular pollfd struct will receive a POLLHUP. I saw any thinkable cases happen. It's only luck if a POLLHUP will finally make it into exceptfds.
Yes, it can happen and it's quite natural sometimes. For example a broken connection is detected when select() sets the READFD and when you try to recv() on that fd you will receive 0 meaning the connection was half-closed, wine's current implementation lets that happen. poll() should behave the same in all systems (posix compliance) but it's well know it does not =)
In my attached test case I have no connection yet, It's about non-blocking sockets where you simply cannot detect "Connection refused". You will get "timeout" instead. In real world this mostly doesn't matters but I can imagine or construct use cases where this little thing could lead to really bad behaviour.
- IMO it's questionable whether we should always put POLLHUP into exceptfds at
all.
I've been thinking about this but only tests can prove this and it will probably vary in the different windows versions.
I guess not. For example with blocking sockets (and no OOB) you should never ever set exceptfds but wine does it sometimes. However this is maybe really no issue because if a programmer is stupid enough to select exceptfds where he would not need it then he probably does something useful when this case happens anyway :)
BUT the important point here in 1.and 2. is related to your fix "avoid false-positive write FDs". These removed POLLHUPs have to go either to readfds or exceptfds because if not then the programmer will think it's just timeout, probably trying select again, probably closing that connection after a timeout period. He does this although he could have known much earlier that connection is dead. Application will still work perfectly but it could have overall performance impact.
- Since we ignore some events (so possibly all events) we must poll again to
really timeout instead of returning 0 without timeouting.
Usually wine coding strategy is to implement things required for real life applications to run. There are plenty network applications running really well in wine currently, [...]
So you fix bugs not if you see them clearly but only after a user run into them?
- POLLPRI (OOB data) is completely ignored currently.
POLLPRI is not needed there currently, usually the strategy is to use the OOBINLINE check and then recv() with MSG_OOB. The wine server already takes care of some POLLPRI stuff as seen in http://source.winehq.org/source/server/sock.c#L324 select() does not return weather there is or not priority data. A real life app example is putty which works in wine currently using the telnet protocol. Maybe you say we should test (POLLIN | POLLPRI) in poll to return the readfds? I don't have objections if that's the case.
POLLPRI has always to go into exceptfds, thats the easiest one to fix.
- What about POLLERR and POLLNVAL? Can't they happen because of our checks
before calling poll?
Yeah, I think POLLNVAL will never happen. And POLLERR is also not required because the current conditions for read/except will allow setting the fd in this case.
Haven't checked that completely. I think you are right about POLLNVAL but have no finally opinion about POLLERR yet although I guess it should only go to writefds.
To fix 1. we need would need a real mapping fd -> "select fds" rather than just mapping array positions. If we had this then we also could more cleanly sort the events into the right "select fds" when we think about 2-5.
I don't understand what's wrong with the current implementation =)
I've simply noticed odd behavior. I am not the usual wine user which is happy about utorrent or whatever. Porting my own developed stuff to win32 I've tried to use wine instead of a real-pain-windows but run into these issues.
To convert the write fd errors in exceptions you could use a fd_set to insert the writefd errors and then in the exceptfs For you could check this fd_set together with the curren check.
If nobody else picks this up I would try to fix some of the points. At the moment less on time maybe when I'll feel the need to do sports at some weekend.
http://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #32 from Bruno Jesus 00cpxxx@gmail.com 2012-02-09 20:32:52 CST --- (In reply to comment #31)
BUT the important point here in 1.and 2. is related to your fix "avoid false-positive write FDs". These removed POLLHUPs have to go either to readfds or exceptfds because if not then the programmer will think it's just timeout, probably trying select again, probably closing that connection after a timeout period. He does this although he could have known much earlier that connection is dead. Application will still work perfectly but it could have overall performance impact.
In this stage of the connection I think they should go to the exceptfds only. I guess the readfds will not be set because it's not used in the connecting process.
So you fix bugs not if you see them clearly but only after a user run into them?
Sometimes that's the strategy, it's the easiest way because there is an ocean of things to do so it's easier to fix what users are interested in. In the other hand you can always add new "todos" to the code and implement them, you need to port your tests into wine and them the fixes are easier to get accepted.
POLLPRI has always to go into exceptfds, thats the easiest one to fix.
Yeah, most of the times. Just don't forget the OOBINLINE usage.
If nobody else picks this up I would try to fix some of the points. At the moment less on time maybe when I'll feel the need to do sports at some weekend.
Excelent, I'll be happy to help but I'll be away from wine and the computer at all in the next 10 days. Just remember: tests first with todos and then implementation and fixes.
https://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #33 from Austin English austinenglish@gmail.com --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.16 or newer) wine?
https://bugs.winehq.org/show_bug.cgi?id=9425
--- Comment #34 from Bruno Jesus 00cpxxx@gmail.com --- Still in 1.7.16.
https://bugs.winehq.org/show_bug.cgi?id=9425
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |38294
https://bugs.winehq.org/show_bug.cgi?id=9425
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |21433
https://bugs.winehq.org/show_bug.cgi?id=9425
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |00cpxxx@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=9425 Bug 9425 depends on bug 21433, which changed state.
Bug 21433 Summary: InqScribe: Installed fine, but no output or UI response when running installed app https://bugs.winehq.org/show_bug.cgi?id=21433
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
https://bugs.winehq.org/show_bug.cgi?id=9425 Bug 9425 depends on bug 38294, which changed state.
Bug 38294 Summary: select() does not report exception on socket after non-blocking connect() fails https://bugs.winehq.org/show_bug.cgi?id=38294
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED
https://bugs.winehq.org/show_bug.cgi?id=9425
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |10f7265270f1ad4e4e1bfec6fb5 | |f06e494d5f579 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #35 from Bruno Jesus 00cpxxx@gmail.com --- This is a long standing bug and I believe we can call it fixed currently, unfortunately as time passed it evolved as a meta bug and each piece of it was fixed and the original issue in this bug was fixed by http://source.winehq.org/git/wine.git/commitdiff/10f7265270f1ad4e4e1bfec6fb5...
https://bugs.winehq.org/show_bug.cgi?id=9425
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #36 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.44.
-
wine-bugs＠winehq.org