Object Creation in thread function

How can I create an Object inside a thread function?....I'm trying to create a new thread that handles a small webserver. The thread fucntion doesn't seem to create the webserver object though. The webserver class itself works fine, but once I try to put it in a seperate thread nothing seems to work.

Heres how I am starting the new thread

Code:

---

UINT StartWebServer(LPVOID param)
{
        WebServer *webServer;
        webServer = new WebServer(HTTPPORT);
        webServer->Run();
        return 1;
}

---

Calling beginthread in another class as follows

AfxBeginThread(&StartWebServer, NULL, THREAD_PRIORITY_NORMAL, 0, 0, NULL);


why does this not work? how can I fix it

Thanks

use

Code:

---

DWORD dwThreadID = 0;
 
CreateThread(NULL , 0 , StartWebServer , NULL , 0 , &dwThreadID);

---

Also, dont forget to clen up the thread handle created by CreateThread, or you will leak handles, adn eventualyl windows will refuse to give you any more.

Just a note, but you don't need to use new to create that object, and so you don't need to delete either.

runtime allocation of a singleton is pretty standard practice.

I highy recommend you do not use CreateThread() to create a thread. Win32 SDK docs recommend using beginthread() and beginthreadex(). For information on why consult the SDK.

Quote:

---

Originally Posted by Bubba

I highy recommend you do not use CreateThread() to create a thread. Win32 SDK docs recommend using beginthread() and beginthreadex(). For information on why consult the SDK.

---

ahem, im calling BS on that one, beginthread is not part of the API, CreateThread is. Aside from that beginthread and beginthreadex both call CreateThread() anyway. You must be using a very very old version of the SDK.

Quote:

---

Originally Posted by MSDN

A thread in an executable that calls the C run-time library (CRT) should use the _beginthreadex and _endthreadex functions for thread management rather than CreateThread and ExitThread; this requires the use of the multi-threaded version of the CRT. If a thread created using CreateThread calls the CRT, the CRT may terminate the process in low-memory conditions.

---

Quoteth the MSDN Online.

Quote:

---

Originally Posted by Elysia

Quoteth the MSDN Online.

---

post the link, because that isnt in either beginthread() or CreateThread() entries.

Quote:

---

Originally Posted by abachler

post the link, because that isnt in either beginthread() or CreateThread() entries.

---

Except it is in the CreateThread entry, as copying what Elysia pasted into Google would have shown.

Sorry about that, I'll do it shortly. It's in CreateThread, though.
Another one:

Quote:

---

Originally Posted by MSDN Live

_beginthread vs CreateThread: which should you use?


A quick browse of ...\VC\crt\src\tidtable.c shows that CRT (the C runtime library) keeps a per-thread data structure, pointed to from a TLS slot.

The per-thread data structure keeps thread-local copies of errno, pointers to some char buffers (eg for strerror(), asctime() etc), floating-point state and a smattering of other stuff.

This is dynamically allocated and initialised by _beginthread(), but obviously CreateThread can't do this since it knows nothing of the CRT. All CRT routines which access this per-thread data structure will lazily create it if it doesn't yet exist, however there's always the risk that this dynamic allocation may fail. This explains the comment "the CRT may terminate the process in low-memory conditions".

So if you don't plan on running out of memory (and who does!) then you can use either _beginthread() or CreateThread(). Do you feel lucky?

---

http://msdn.microsoft.com/en-us/library/ms682453.aspx

Both are near the bottom.

ah yes i see it at the very bottom now. Still, that advice is only for executables that use the CRT, it is not for applications that do not use teh CRT, so bubbas assertion that the SDK recommends against the use of CreateThread was misleading. It only recommends against it in that particular case. Generally it is particular to the use of the DLL version of the CRT, since the thread may terminate if it cannot link to the DLL (due to memory constraints). It is a non-issue with the static link version of the CRT, since the thread requires only its thread stack, which if it is not available causes thread creation to fail. despite the documentation, beginthread suffers from this same behavior, in that the thread stack can be allocated, and the function return success prior to the threads initialization code, which can then fail, terminating the thread.

In any case beginthread calls createthread or vice versa depending on the implimentation/OS version, so the benefit of calling beginthread vs createthread is dubious at best. I have never run into a situation where low memory conditions caused thread termination, and I very often push the memory allocation to its limits. In fact I had one application that specifically kept allocating objects until HeapAlloc() failed. It never once terminated a thread. My feeling is this is a legacy warning that is no longer necessary, but is left in in case someone has this issue.

Abachler: Do you think it's realistic to believe that a WebServer can be written without using any C runtime calls? In the posted code, new would be one example of such code - so for THIS particular thread, the suggestion to NOT use CreateThread would be valid.

[If we assume that new for WebServer hasn't been overloaded with a function that allocates memory directly from the Win32 API - which is of course posisble, but I find it somewhat unlikely].

--
Mats

afaik you can write a complete webserver using nothing but API calls (i.e. no CRT requirements).

Winsock functions - no crt req's

I suppose you can, but wouldn't that be a little inconvenient?

Quote:

---

Originally Posted by abachler

afaik you can write a complete webserver using nothing but API calls (i.e. no CRT requirements).

Winsock functions - no crt req's

---

I didn't ask "is it possible", but "do you think it's practical". That's not the same thing. Some CRT functions are trivial to avoid, but others are definitely very hard to avoid because the C++ language in itself is calling them (such as new will call some functionality to allocate memory that isn't directly HeapAlloc() or whatever API function is used for this purpose).

It would also be quite beneficial to be able to use buffered IO functions such as stream or stdio functins to produce textual output from various forms of integer/floating point values, perhaps. Yes, you can write your own versions of those, but it is far from practical to do so.

The only time I'd expect CreateThread to be a better choice is if your thread is PURELY calculations, or very simple API function calls.

--
Mats

Its entirely practical if you are writing a web server, I've written several network services that used no CRT. In fact, I'm at a loss as to what you would need that does require CRT. Perhaps you could provide an example of a gotta have it function that requires CRT.

No you haven't. You don't understand how much the CRT does for you. For example it calls the constructors of all your global objects for you. If you link with something called tinycrt then your global objects will not be constructed! What about new and delete, feel like implementing those yourself? I'm just warming up here. Trust me it's simply not practical.

Anyway, you're totally reaching. It seems that the one you're trying to convince is yourself though. Serious Windows multi-threading programmers know that you should use _beginthread or _beginthreadex and not CreateThread.

I'm pretty god damned sure I'm more qualified to say what I have and haven't written than you.

Please keep the posts clean or I'll close the thread.