Singularity-Viewer/SingularityViewer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Rename CurlResponderBuffer to BufferedCurlEasyRequest and derive it from CurlEasyRequest

Browse Source 
Every curl transaction is a AICurlEasyRequestStateMachine which has a
AICurlEasyRequest as member, which is a reference counting pointer to
a ThreadSafeBufferedCurlEasyRequest. And now BufferedCurlEasyRequest is
derived from CurlEasyRequest which is derived from CurlEasyHandle, but
neither are used separatedly.
This commit is contained in:
Aleric Inglewood
2012-11-02 18:41:23 +01:00
parent 1e1f5e8193
commit 72bde5234a
8 changed files with 170 additions and 272 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
indra/llmessage/llhttpclient.h
View File

@@ -84,15 +84,6 @@ public:
* associated CurlResponderBuffer, however, if everything works correctly, then normally a
* responder is deleted in CurlResponderBuffer::removed_from_multi_handle by setting
* mReponder to NULL.
*
* Note that the lifetime of CurlResponderBuffer is (a bit) shorter than the associated
* CurlEasyRequest (because of the order of base classes of ThreadSafeBufferedCurlEasyRequest)
* and the callbacks, as set by prepRequest, only use those two.
* A callback locks the CurlEasyRequest before actually making the callback, and the
* destruction of CurlResponderBuffer also first locks the CurlEasyRequest, and then revokes
* the callbacks. This assures that a Responder is never used when the objects it uses are
* destructed. Also, if any of those are destructed then the Responder is automatically
* destructed too.
*/
class ResponderBase : public AICurlResponderBufferEvents {
public: