The attached patch implements a socket queue in the DLL side and implements WSACleanup. For now the socket list does not have any parameter but my target is to add more stuff to it and reduce the server calls. Any comments are appreciated.
Best wishes, Bruno
On Sun, Dec 29, 2013 at 4:21 PM, David Quintana (gigaherz) gigaherz@gmail.com wrote:
I have no knowledge about windows sockets, but DLLs are not shared across processes. If a DLL wants shared memory it has to map it explicitly, like everything else. On the other hand threads do share all memory, and windows provides thread-local storage to allow thread-specific variables.
On 29 Dec 2013 19:15, "Bruno Jesus" 00cpxxx@gmail.com wrote:
Hi, in an attempt to fix bugs 18670 and 26031 I would like to try implementing WSACleanup more properly. My limited knowledge in the interactions between the ws2_32 dll and wine server makes me think this is easy.
The idea is to add the created socket in WSASocketW in a list and remove it from the list when closesocket is called. When the last WSACleanup is called it would iterate through the socket list and destroy the remaining sockets.
When WSASocketW is called it calls the server to create the socket, when closesocket is called the server is also called and the function sock_destroy takes care of shutting down the socket.
Currently I'm thinking about doing this in the dll side because the server is not aware of WSACleanup, but maybe it should because it needs to avoid calling any async operation completion.
My questions are:
- When I open 2 programs that use ws2_32 dll the global variables
memory is not shared, right? Otherwise the WSAStartup/Cleanup count could be messed up if one application didn't call the Cleanup function. I hope this true so the socket list would not have to take care of different processes id.
I understand that one application can have multiple threads and that's what the struct per_thread_data is about, but I hope the dll is not shared among different processes.
- Is this a reasonable approach? If yes, is there any example of a
critical protected list (add, iterate, remove items) that I could use?
Best wishes, Bruno
On Fri, Feb 21, 2014 at 5:55 PM, Bruno Jesus 00cpxxx@gmail.com wrote:
The attached patch implements a socket queue in the DLL side and implements WSACleanup. For now the socket list does not have any parameter but my target is to add more stuff to it and reduce the server calls. Any comments are appreciated. ...
At least in the server handles are converted into indices in a table: http://source.winehq.org/source/server/handle.c#L70
Is there some reason that you did not do it this way?
Best, Erich
On Fri, Feb 21, 2014 at 10:06 PM, Erich E. Hoover erich.e.hoover@gmail.com wrote:
On Fri, Feb 21, 2014 at 5:55 PM, Bruno Jesus 00cpxxx@gmail.com wrote:
The attached patch implements a socket queue in the DLL side and implements WSACleanup. For now the socket list does not have any parameter but my target is to add more stuff to it and reduce the server calls. Any comments are appreciated. ...
At least in the server handles are converted into indices in a table: http://source.winehq.org/source/server/handle.c#L70
Is there some reason that you did not do it this way?
I did it in the simplest way I found, I was not aware the server did that, what are the advantages?
Best, Erich
Bruno
On Fri, Feb 21, 2014 at 6:12 PM, Bruno Jesus 00cpxxx@gmail.com wrote:
... I did it in the simplest way I found, I was not aware the server did that, what are the advantages?
I believe that it was done this way so that it is only necessary to resize the list memory when growing the table (since applications can add and remove handles very rapidly and copying is expensive). It also makes it very fast to find an entry since you don't need to search the list, you just jump to its offset.
Best, Erich
On Fri, Feb 21, 2014 at 10:18 PM, Erich E. Hoover erich.e.hoover@gmail.com wrote:
I believe that it was done this way so that it is only necessary to resize the list memory when growing the table (since applications can add and remove handles very rapidly and copying is expensive). It also makes it very fast to find an entry since you don't need to search the list, you just jump to its offset.
Ok, thanks. I will try to understand it and rewrite the patch.
Regards, Bruno
-
Bruno Jesus -
Erich E. Hoover