Changeset View
Changeset View
Standalone View
Standalone View
ps/trunk/source/ps/UserReport.cpp
Show First 20 Lines • Show All 341 Lines • ▼ Show 20 Lines | shared_ptr<CUserReport> report; | ||||
return false; | return false; | ||||
report = m_ReportQueue.front(); | report = m_ReportQueue.front(); | ||||
m_ReportQueue.pop_front(); | m_ReportQueue.pop_front(); | ||||
} | } | ||||
ConstructRequestData(*report); | ConstructRequestData(*report); | ||||
m_RequestDataOffset = 0; | m_RequestDataOffset = 0; | ||||
m_ResponseData.clear(); | m_ResponseData.clear(); | ||||
m_ErrorBuffer[0] = '\0'; | |||||
curl_easy_setopt(m_Curl, CURLOPT_POSTFIELDSIZE_LARGE, (curl_off_t)m_RequestData.size()); | curl_easy_setopt(m_Curl, CURLOPT_POSTFIELDSIZE_LARGE, (curl_off_t)m_RequestData.size()); | ||||
SetStatus("connecting"); | SetStatus("connecting"); | ||||
#if DEBUG_UPLOADS | #if DEBUG_UPLOADS | ||||
TIMER(L"CUserReporterWorker request"); | TIMER(L"CUserReporterWorker request"); | ||||
#endif | #endif | ||||
CURLcode err = curl_easy_perform(m_Curl); | CURLcode err = curl_easy_perform(m_Curl); | ||||
lyv: Not related to this revision proposal, but is it a good idea to not use a curl_multi for this? | |||||
elexisAuthorUnsubmitted Not Done Inline ActionsThe UserReporter is running in a separate thread, so it's not a problem to use the synchroneous / blocking curl easy handlers. elexis: The UserReporter is running in a separate thread, so it's not a problem to use the synchroneous… | |||||
lyvUnsubmitted Not Done Inline Actions
Ah, I see. lyv: > The UserReporter is running in a separate thread,
Ah, I see. | |||||
#if DEBUG_UPLOADS | #if DEBUG_UPLOADS | ||||
printf(">>>\n%s\n<<<\n", m_ResponseData.c_str()); | printf(">>>\n%s\n<<<\n", m_ResponseData.c_str()); | ||||
#endif | #endif | ||||
if (err == CURLE_OK) | if (err == CURLE_OK) | ||||
{ | { | ||||
long code = -1; | long code = -1; | ||||
Show All 11 Lines | if (err == CURLE_OK) | ||||
{ | { | ||||
CScopeLock lock(m_WorkerMutex); | CScopeLock lock(m_WorkerMutex); | ||||
m_Shutdown = true; | m_Shutdown = true; | ||||
return false; | return false; | ||||
} | } | ||||
} | } | ||||
else | else | ||||
{ | { | ||||
SetStatus("failed:" + CStr::FromInt(err) + ":" + m_ErrorBuffer); | std::string errorString(m_ErrorBuffer); | ||||
if (errorString.empty()) | |||||
errorString = curl_easy_strerror(err); | |||||
SetStatus("failed:" + CStr::FromInt(err) + ":" + errorString); | |||||
} | } | ||||
// We got an unhandled return code or a connection failure; | // We got an unhandled return code or a connection failure; | ||||
// push this report back onto the queue and try again after | // push this report back onto the queue and try again after | ||||
// a long interval | // a long interval | ||||
{ | { | ||||
CScopeLock lock(m_WorkerMutex); | CScopeLock lock(m_WorkerMutex); | ||||
▲ Show 20 Lines • Show All 247 Lines • Show Last 20 Lines |
Wildfire Games · Phabricator
Not related to this revision proposal, but is it a good idea to not use a curl_multi for this? If the report get sufficently large, this could cause issues, no?