Each thread make easy job (see code below): Create COM WinHttpRequest, open
Post method/URL and send data.
But tracing and printed output show that processing was serialized somewhere
on WaitForResponse or ResponseText method.
TcpTrace shows that tread already has got response, but thread waits before
printf while other threads receive their responses.
BTW, if I use synchronal send, all threads are serialized by Send methods
(only one connection for each time).
Configuration: Win2K, SP2, winhttp5.dll ver.5.0.2613.0
So, is it possible to use WinHttp without any serializaion (as WinInet after
editing related registry settings) in multithread environment?
------------------------------------------------------------------------
#define STRICT
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0400
#endif
#include <stdio.h>
#include <comdef.h>
#include <conio.h>
#import "winhttp5.dll" rename_namespace("WINHTTP")
DWORD WINAPI ThreadFunc( LPVOID lpParam) ;
int main(int argc, char* argv[])
{
printf("Hello World!\n");
for(int i=1;i < 20; i++)
{
CreateThread(NULL, 0, ThreadFunc, NULL, NULL, NULL);
}
_getch();
// terminate threads, relese handles etc
...
return 0;
}
DWORD WINAPI ThreadFunc( LPVOID lpParam)
{
CoInitializeEx(NULL,COINIT_MULTITHREADED);
WINHTTP::IWinHttpRequestPtr wsender(__uuidof(WINHTTP::WinHttpRequest));
printf("BEGIN\n");
for(int i=1;i < 1000;i++)
{
try
{
wsender->Open(L"POST",L"http://localhost:8080/someurl", VARIANT_TRUE);
wsender->Send(L"post data");
wsender->WaitForResponse();
printf("OUT:");
printf(" %S\n",(WCHAR*)wsender->ResponseText);
}
catch (_com_error &err)
{
printf("COM ERROR: %S",(WCHAR*)err.Description());
}
}
CoUninitialize();
}
The serialization problem is due to a mismatch of COM threading models. Your
application is using the WinHttpRequest component from the Multi-Threaded
COM Apartment (MTA). Your application is running in the MTA due to the
CoInitializeEx(COINIT_MULTITHREADED) call. However, WinHttpRequest is a
Single-Threaded Apartment (STA) component (e.g., ThreadingModel=Apartment).
Instantiating STA components from the MTA is not recommended--doing so will
cause method calls to be marshaled from the caller's thread in the MTA to
the STA thread that the object instance lives on. This degrades performance
and should be avoided. Furthermore, the COM runtime will run multiple STA
objects on the same thread, so all of your threads in the MTA are calling
into a single STA thread, thereby causing the serialization.
Your application's threads that need to use WinHttpRequest (or any other STA
component) should be initialized with their own single-threaded apartments.
That is, specify COINIT_APARTMENTTHREADED when calling CoInitializeEx.
If you are writing a multithreaded C++ application and wish to avoid using
STA threads, then consider using the WinHTTP Win32 API instead. WinHTTP's
Win32 API is multi-thread safe, and offers more functionality than the
WinHttpRequest COM component (at the expense of more complicated
programming).
One last thing to mention: if you upgrade to Windows 2000 SP3, you can use
WinHTTP version 5.1 (winhttp.dll), which ships with the OS.
Regards,
Stephen Sulzer
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
<andr> wrote in message news:uNPFlK6nCHA.2404@TK2MSFTNGP10...
But why MS ships WinHttpRequest COM object as Apartment (STA)?
Is it safe to change threading model in registry to Both?
Otherwise we have to write our one WinHttpRequest COM object using WinHTTP
Win32 API.with only one difference: it supports Both threading model.
Regards, Andrej
"Stephen Sulzer [Microsoft]" <ssu...@online.microsoft.com> wrote in message
news:exe5#DBoCHA.2404@TK2MSFTNGP10...
WinHttpRequest is an STA only component. The component was designed
primarily for use by ASP applications; ASP pages execute in an STA
environment, so an STA component was sufficient. Changing the threading
model to Both is not supported.
Regards,
Stephen Sulzer
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
<andr> wrote in message news:O2n9xLDoCHA.2188@TK2MSFTNGP09...