If a wxWebRequestCURL object is canceled or deleted before its transfer
is complete, we need to manually close its active socket. Record each
transfer’s active socket in wxWebSessionCURL::SocketCallback so can use
it if needed.
Previously, this was done using curl_easy_getinfo, but this required
some compile time and run time checks and could fail in some specific
cases. Recording the socket ourselves significantly simplifies the code
and should always work.
When using the socket poller implementation using wxEventLoopSource
objects to monitor sockets, the operation
wxEventLoopBase::AddSourceForFD(... can sometimes return NULL. In these
cases the socket will not be monitored as needed. The only option seems
to be to cancel the transfer and report a failure
Previously wxWebRequestCURL objects were canceled by removing their
CURL easy handle from the CURLM multihandle. Unfortunately the really
only pauses the connection and does not truly cancel it. This commit
tries to stop the transfer by retrieving the active socket from the CURL
handle for the transfer and closing it.
There are some complications in doing this because the option curl uses
to get the socket have changed over the years. A combination of compile
time and run time checks are used to use the appropriate options to get
the socket. However in the case of 64bit windows using a curl version
older than 7.45.0 simply won’t have an usable option. In this case,
it seems nothing can be done.
At various points in a transfer being managed by the wxWebSessionCURL
class we need to perform operations on a wxWebRequestCURL object.
However it’s possible for the request object to be deleted while the
transfer is in progress.
To ensure that the request objects are valid, keep track of the request
objects with a hash map. Objects are added to the map when a transfer is
started and removed when the transfer is complete or in the request’s
destructor.
Currently for wxWebRequestCURL objects using memory storage, a download
is processed by appending to a wxMemoryBuffer each time the write
callback is called. For a large transfer, this can result in many, many
reallocation calls and can block the main application.
This commit uses the progress callback for wxWebRequestCURL objects
added in a previous commit to set a minimum size for the buffer as soon
as it is known.
This commit adds a progress callback for use with wxWebRequestCURL
objects. This has some complications because over the years curl has
changed the signature of the callback.
A combination of compile-time and run-time checks is used to make sure
the appropriate callback and preferred return value are used.
Instead of having wxWebSessionCURL run a worker thread that uses curl
to monitor and process network activity, set up a separate socket
poller class to monitor socket activity. The socket poller class will
throw an event back to wxWebSessionCURL when it detects activity on the
sockets so that it can tell curl to process the activity in the main
thread.
Under MSW, don't set the state to State_Cancelled as soon as Cancel()
was called, as the request was still used from the other threads
afterwards, resulting in race conditions and crashes.
Fix this by just removing the SetState(State_Cancelled) call from the
main thread, as it was redundant anyhow. This also makes the behaviour
correspond to the documentation, which indicates that Cancel() works
asynchronously.
Also ensure, for all backends, that we actually cancel the request only
once, even if public Cancel() is called multiple times. This required
renaming the existing wxWebRequestImpl::Cancel() to DoCancel().
Also use critical section instead of a mutex, as this is more efficient
under MSW.
Main purpose of this commit is to make it clear that this mutex/critical
section is only used together with the data from the same struct.
No real changes.
Don't force the application code to deal with wxObjectDataPtr<> or,
worse, calling {Inc,Dec}Ref() manually by hiding it inside the wx
objects themselves and giving the value-like semantics to them.
There should be no real changes in the behaviour, but the API does
change significantly. Notably, wxWebRequest is not a wxEvtHandler itself
any longer, as this would be incompatible with the value semantics, and
an event handler needs to be specified when creating it, so that it
could be notified about the request state changes.
Having wxWebSessionFactory part of the public API implies keeping
compatibility with the possible ways of implementing it which is too
restrictive for no good reason, so move this class to the private header
and don't document it nor wxWebSession::RegisterFactory() (which is now
private).
