mirror of
https://github.com/moparisthebest/curl
synced 2024-12-21 23:58:49 -05:00
John Clayton's weird explorations in the wonders of the windows tcp/ip
stack ;-)
This commit is contained in:
parent
51d602f973
commit
bd830c6f4d
@ -14,3 +14,63 @@ may have been fixed since this was written!
|
||||
* libcurl does not deal nicely with files larger than 2GB
|
||||
|
||||
* GOPHER transfers seem broken
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
Q: My program blows up when I run lots of curl_easy_perform() calls on a
|
||||
single thread
|
||||
Q: My program dies when a single thread re-enters the win32 select() call
|
||||
via curl_easy_perform()
|
||||
Q: --- add your own flavour here ---
|
||||
|
||||
Single Threaded Re-Entracy
|
||||
--------------------------
|
||||
|
||||
There is a glitch / trick to using cURL on Win32 related to re-entrancy.
|
||||
This experience was gained on verion 7.9.4 using Windows NT SP3 in a banking
|
||||
environment (just in case you wanted to know).
|
||||
|
||||
If you have already called curl_easy_perform(), and *somehow* you cause your
|
||||
single thread of execution to make another call to curl_easy_perform() - the
|
||||
windows socket() call used to create a new socket for the second connection
|
||||
can return with 10044 / 10043 error codes.
|
||||
|
||||
The WSA errors we experienced are:
|
||||
WSAEPROTONOSUPPORT
|
||||
(10043)
|
||||
Protocol not supported.
|
||||
The requested protocol has not been configured into the system, or no
|
||||
implementation for it exists. For example, a socket call requests a
|
||||
SOCK_DGRAM socket, but specifies a stream protocol.
|
||||
|
||||
WSAESOCKTNOSUPPORT
|
||||
(10044)
|
||||
Socket type not supported.
|
||||
The support for the specified socket type does not exist in this address
|
||||
family. For example, the optional type SOCK_RAW might be selected in a
|
||||
socket call, and the implementation does not support SOCK_RAW sockets at
|
||||
all.
|
||||
|
||||
We have experienced this by creating a timer that ticks every 20ms, and on
|
||||
the tick making a curl_easy_perform() call. The call usually completed in
|
||||
about 300ms. And we expected (before this test) that the timer would NOT be
|
||||
fired during a call to curl_easy_perform(), howvever, while the first
|
||||
curl_easy_perform() is running a tick *is* fired by the windows API somehow,
|
||||
and we then call curl_easy_perform() again - thus single threaded
|
||||
re-entrancy is achieved.
|
||||
|
||||
Notes:
|
||||
* We made sure that a new CURL structure was being used for each
|
||||
curl_easy_perform() request, and that the curl_global_init() had been called
|
||||
beforehand.
|
||||
* I'm happy to answer any questions about this problem to try to track it
|
||||
down.
|
||||
* Once the socket() call started failing, there is no hope - it never works
|
||||
again.
|
||||
* Slowing the timer down to give each request enough time to complete solves
|
||||
this problem completely.
|
||||
|
||||
If anyone has the source code to the WinNT implementation of socket() and
|
||||
can figure out WHY this can occur, more tracing can be performed.
|
||||
|
||||
John Clayton <John.Clayton at barclayscapital.com>
|
||||
|
Loading…
Reference in New Issue
Block a user